{ "certificationPackageOverviewUri": "https://placeholder.invalid/certification-package-overview-pending-cpo", "metadata": { "version": "1.0.0", "lastUpdated": "2026-10-27T18:23:26.979Z", "updateSource": "Paramify, Inc." }, "portsAndProtocols": [], "securityControls": [], "fedRampRequirements": [ { "frrID": "AFC-CSO-CRA", "frrImplementationStatus": "Implemented", "frrImplementation": [ "When FedRAMP Security Emails are received, the @GRC Admin reviews the required actions in the body of messages that require an elevated response (Emergency, Emergency Test, and Important) routes Emergency messages to a senior security official ensures the required actions are completed within the timeframe specified in the email from @FedRAMP Project Management Office.\n\nIf the addressing for #THIS ORGANIZATION's FedRAMP Security Inbox changes, the @GRC Admin will immediately notify the @FedRAMP Project Management Office by emailing info@fedramp.gov with the name and FedRAMP ID of the cloud service offering and the updated email address. Action on FedRAMP Security Emails : Action on FedRAMP Security Emails has an attestation that ensures that the @GRC Admin monitors the FedRAMP Security Inbox, routes \"Emergency\" messages to senior officials, ensures actions are completed within PMO-mandated timeframes, and updates info@fedramp.gov immediately if the contact email changes.", "#THIS ORGANIZATION assesses internal controls through [Continuous Monitoring Process: @Continuous Monitoring Process], using [GRC Tool: @Paramify SaaS] to establish the frequency of occurrence (e.g. monthly, quarterly, annually) or triggers (e.g. a security event), as well as the internal control owner.", "Identified issues resulting from [Continuous Monitoring Process: @Continuous Monitoring Process] are given owners and tracked to remediation via [GRC Tool: @Paramify SaaS]." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "AFC-CSO-INB", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Change Control Board is notified of deployed changes via [Event Notifications: @OpsGenie].", "Liferay SaaS uses Gmail, a component of Google Workspace, to implement FedRAMP Security Inbox Configuration controls.", "Liferay SaaS configures a security inbox (fedramp@#THIS ORGANIZATION.com) in [Security Inbox: @Gmail] to receive emails from official fedramp.gov or gsa.gov email address and send auto-replies to verify the inbox is active and reachable by @FedRAMP Project Management Office. When Emergency, Emergency Test, or Important FedRAMP emails are received, alert notifications are sent to the @InfoSec Admin in [Event Notifications: @OpsGenie].\n\nNote: Replace following text and brackets with appropriate validator mention and context.\n\n\\[FedRAMP Security Inbox Configuration : FedRAMP Security Inbox Configuration\\] has an attestation that ensures that the organization configures the fedramp@ inbox in [Security Inbox: @Gmail] with enabled auto-replies for reachability verification, and creates automation rules to route \"Emergency\" alerts directly to the @InfoSec Admin", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan" ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "AFC-CSO-NOC", "frrImplementationStatus": "Implemented", "frrImplementation": [ "When FedRAMP Security Emails are received, the @GRC Admin reviews the required actions in the body of messages that require an elevated response (Emergency, Emergency Test, and Important) routes Emergency messages to a senior security official ensures the required actions are completed within the timeframe specified in the email from @FedRAMP Project Management Office.\n\nIf the addressing for #THIS ORGANIZATION's FedRAMP Security Inbox changes, the @GRC Admin will immediately notify the @FedRAMP Project Management Office by emailing info@fedramp.gov with the name and FedRAMP ID of the cloud service offering and the updated email address. Action on FedRAMP Security Emails : Action on FedRAMP Security Emails has an attestation that ensures that the @GRC Admin monitors the FedRAMP Security Inbox, routes \"Emergency\" messages to senior officials, ensures actions are completed within PMO-mandated timeframes, and updates info@fedramp.gov immediately if the contact email changes.", "The Change Control Board is notified of deployed changes via [Event Notifications: @OpsGenie].", "#THIS ORGANIZATION maintains a dedicated notification portal (https://status.paramify.com) to update customers on planned maintenance and current Liferay SaaS availability." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "AFC-CSO-RCV", "frrImplementationStatus": "Implemented", "frrImplementation": [ "When FedRAMP Security Emails are received, the @GRC Admin reviews the required actions in the body of messages that require an elevated response (Emergency, Emergency Test, and Important) routes Emergency messages to a senior security official ensures the required actions are completed within the timeframe specified in the email from @FedRAMP Project Management Office.\n\nIf the addressing for #THIS ORGANIZATION's FedRAMP Security Inbox changes, the @GRC Admin will immediately notify the @FedRAMP Project Management Office by emailing info@fedramp.gov with the name and FedRAMP ID of the cloud service offering and the updated email address. Action on FedRAMP Security Emails : Action on FedRAMP Security Emails has an attestation that ensures that the @GRC Admin monitors the FedRAMP Security Inbox, routes \"Emergency\" messages to senior officials, ensures actions are completed within PMO-mandated timeframes, and updates info@fedramp.gov immediately if the contact email changes.", "The Change Control Board is notified of deployed changes via [Event Notifications: @OpsGenie].", "Liferay SaaS uses Gmail, a component of Google Workspace, to implement FedRAMP Security Inbox Configuration controls.", "Liferay SaaS configures a security inbox (fedramp@#THIS ORGANIZATION.com) in [Security Inbox: @Gmail] to receive emails from official fedramp.gov or gsa.gov email address and send auto-replies to verify the inbox is active and reachable by @FedRAMP Project Management Office. When Emergency, Emergency Test, or Important FedRAMP emails are received, alert notifications are sent to the @InfoSec Admin in [Event Notifications: @OpsGenie].\n\nNote: Replace following text and brackets with appropriate validator mention and context.\n\n\\[FedRAMP Security Inbox Configuration : FedRAMP Security Inbox Configuration\\] has an attestation that ensures that the organization configures the fedramp@ inbox in [Security Inbox: @Gmail] with enabled auto-replies for reachability verification, and creates automation rules to route \"Emergency\" alerts directly to the @InfoSec Admin", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan" ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CCM-OCR-AVL", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION adheres to CR26 FedRAMP 20x Continuous Monitoring frequencies:\n\n- Ongoing monitoring of information system and auditable events, with incident reporting as necessary\n\n- Weekly audit review, analysis and reporting\n\n- Monthly vulnerability scanning, internal reporting of security status, flaw remediation, update of POA&M, and verification of security functions\n\n- Change/refresh authenticators every 60 days\n\n- Quarterly disablement of inactive user accounts\n\n- Annual activities including review and update of security policies and procedures, verification of continued access for account holders, security awareness and training, security assessment by a 3PAO, penetration testing, contingency plan training and testing, incident response training and testing, and review and update of access agreements and rules of behavior\n\n- Prevent reuse of identifiers every two years\n\n- Reauthorize Liferay SaaS every three years, and review and update position categorizations and risk assessments as necessary\n\n- Rescreen personnel every five years.", "#THIS ORGANIZATION publishes an Ongoing Certification Report (OCR) to all necessary parties every 3 months on a regular cycle spread out from a consistent point in each quarter. The OCR covers the entire period since the previous report and includes, at minimum:\n\n- Changes to FedRAMP Certification Data since the last OCR\n- Planned changes to FedRAMP Certification Data for at least the next 3 months\n- Accepted vulnerabilities\n- Transformative changes\n- Updated recommendations or best practices for security, configuration, or usage\n- A list of all agencies directly using the product\n- FedRAMP Reportable Incidents, or an attestation that no such incidents occurred\n- Lessons learned and changes made as a result of any FedRAMP Reportable Incidents\n\nThe target date for the next OCR is published alongside other public FedRAMP Certification Data. Sensitive information that would likely have an adverse effect on Liferay SaaS is not disclosed in the OCR." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nInspected the entity’s website to determine that changes to commitments, requirements and responsibilities were communicated to third-parties, external users and customers via the entity’s website.\n\n**Result**\n\nNo exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "CCM-OCR-NRD", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION publishes an Ongoing Certification Report (OCR) to all necessary parties every 3 months on a regular cycle spread out from a consistent point in each quarter. The OCR covers the entire period since the previous report and includes, at minimum:\n\n- Changes to FedRAMP Certification Data since the last OCR\n- Planned changes to FedRAMP Certification Data for at least the next 3 months\n- Accepted vulnerabilities\n- Transformative changes\n- Updated recommendations or best practices for security, configuration, or usage\n- A list of all agencies directly using the product\n- FedRAMP Reportable Incidents, or an attestation that no such incidents occurred\n- Lessons learned and changes made as a result of any FedRAMP Reportable Incidents\n\nThe target date for the next OCR is published alongside other public FedRAMP Certification Data. Sensitive information that would likely have an adverse effect on Liferay SaaS is not disclosed in the OCR." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CCM-QTR-MTG", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION hosts a synchronous Quarterly Review every 3 months, open to all necessary parties, to review aspects of the most recent Ongoing Certification Report most relevant to agencies. Quarterly Reviews are scheduled within 10 business days of publishing an OCR and at least 3 business days after its release. A registration link or downloadable calendar invitation with meeting details is distributed to all necessary parties in advance.\n\nThe @GRC Admin presents information determined to be of interest, use, or otherwise relevant to agencies, and may include additional content beyond the OCR. Quarterly Reviews are recorded or transcribed, and the recording or transcript is made available to all necessary parties. Sensitive information that would likely have an adverse effect on Liferay SaaS is not irresponsibly disclosed. Third parties are not invited unless they have specific relevance to the content being reviewed.", "The @Auditor conducts annual security assessments for Liferay SaaS, documenting results in a Security Assessment Report (SAR). Confirmed findings are addressed in the [Risk Remediation Process: @Risk Remediation Process] by the GRC Admin.", "The GRC Admin updates the Security Assessment Plan of Liferay SaaS annually, including security controls and enhancements, assessment procedures, and team roles and responsibilities. The assessment plan is approved by the @Authorizing Official prior to the commencement of the assessment." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CDS-CSO-AVR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION adheres to CR26 FedRAMP 20x Continuous Monitoring frequencies:\n\n- Ongoing monitoring of information system and auditable events, with incident reporting as necessary\n\n- Weekly audit review, analysis and reporting\n\n- Monthly vulnerability scanning, internal reporting of security status, flaw remediation, update of POA&M, and verification of security functions\n\n- Change/refresh authenticators every 60 days\n\n- Quarterly disablement of inactive user accounts\n\n- Annual activities including review and update of security policies and procedures, verification of continued access for account holders, security awareness and training, security assessment by a 3PAO, penetration testing, contingency plan training and testing, incident response training and testing, and review and update of access agreements and rules of behavior\n\n- Prevent reuse of identifiers every two years\n\n- Reauthorize Liferay SaaS every three years, and review and update position categorizations and risk assessments as necessary\n\n- Rescreen personnel every five years.", "Liferay SaaS inherits FedRAMP-compatible Trust Center controls from Paramify Cloud - 20x Moderate.", "#THIS ORGANIZATION maintains a dedicated notification portal (https://status.paramify.com) to update customers on planned maintenance and current Liferay SaaS availability.", "#THIS ORGANIZATION considers Liferay SaaS product portions highly available with a 1-hour recovery-time objective (RTO). Administrative portions managed by Cloud Service Providers with SLAs for service availability.", "Liferay SaaS inherits Trust Center Agency Access Management controls from Paramify Cloud - 20x Moderate." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CDS-CSO-IRP", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The GRC Admin is responsible for managing the development, documentation and dissemination of both [Data Protection Procedures: @Data Protection Procedures] and [Data Protection Policies: @Data Protection Policies].", "The GRC Admin reviews [Data Protection Policies: @Data Protection Policies] annually and updates the version history table with the most recent review date and version number.", "The GRC Admin reviews [Data Protection Procedures: @Data Protection Procedures] annually and updates the version history table with the most recent review date and version number.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CDS-CSO-PSM", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Liferay SaaS inherits Certification Data Generation controls from Paramify Cloud - 20x Moderate.", "#THIS ORGANIZATION identifies a set of information resources to assess for FedRAMP authorization that includes all information resources that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering. This includes configurations and use of third-party information resources. #THIS ORGANIZATION clearly identifies and documents the justification, mitigation measures, compensating controls, and potential impact to federal customer data from the configuration and usage of non-FedRAMP authorized third-party information resources, including metadata (and metadata about federal customer data).\n\n#THIS ORGANIZATION clearly identifies, documents, and explains information flows and impact levels for ALL information resources. Certain categories of cloud computing products and services are specified as entirely outside the scope of FedRAMP by the Director of the Office of Management and Budget. All such products and services are therefore not included in the cloud service offering for FedRAMP. #THIS ORGANIZATION reviews best practices and technical assistance provided separately by FedRAMP for help with applying the Minimum Assessment Scope as needed.\n\nNote: Replace following text and brackets with appropriate validator mention and context.\n\nMinimum Assessment Scope Validators for [Data Wiping Tool] and [Anti-Malware: @Prisma Cloud] ensure all resources are in scope when continuous evidence validations run.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CDS-CSO-PUB", "frrImplementationStatus": "Implemented", "frrImplementation": [ "@Customer Success Engineer maintains publicly accessible guidance that includes:\n\n- Instructions on how to securely access, configure, operate, and decommission top-level administrative accounts\n\n- Explanation of security-related settings operable by top-level administrative accounts and their security implications\n\n- Explanation of security-related settings operable by privileged accounts and their security implications\n\nNote: Replace following text and brackets with appropriate validator mention and context.\n\n\\[Administrative & Privileged Account Documentation : Administrative & Privileged Account Documentation\\] has an attestation that ensures that the @Customer Success Engineer maintains publicly accessible documentation detailing the lifecycle (access, configure, operate, decommission) and security implications of settings for both top-level administrative and privileged accounts.", "Liferay SaaS inherits Documentation on Trust Center controls from Paramify Cloud - 20x Moderate.", "Liferay SaaS inherits FedRAMP-compatible Trust Center controls from Paramify Cloud - 20x Moderate.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC2.3#7: Inspected the entity’s website to determine that changes to commitments, requirements and responsibilities were communicated to third-parties, external users and customers via the entity’s website.\n\nCC2.3#10: Inspected the entity’s website to determine that changes to commitments and requirements relating to confidentiality were communicated to third-parties, external users, and customers via the entity’s website.\n\n**Result**\n\nCC2.3#7: No exceptions noted.\n\nCC2.3#10: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "CDS-CSO-SVC", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Authorizing Official assesses remaining system vulnerabilities and determines risk acceptability for Customer/Agency operations. Based on the accreditation package and consultation, they may issue a provisional accreditation decision with/without restrictions, or not authorize for operation. If restrictions are placed, a detailed POA&M with corrective actions is required for a future updated accreditation package.", "Liferay SaaS inherits FedRAMP-compatible Trust Center controls from Paramify Cloud - 20x Moderate.", "#THIS ORGANIZATION manages a single, owned process for completing and submitting the official FedRAMP forms and packages required to onboard Liferay SaaS to the FedRAMP Marketplace and FedRAMP Certification. The @GRC Admin completes each required FedRAMP form before submission, including the FedRAMP Marketplace Provider Listing Request Form used to request a Marketplace listing (or updates to an existing listing) and the FedRAMP Certification Application Form used to request an initial assessment. Before requesting a listing or an update, #THIS ORGANIZATION addresses the FedRAMP Marketplace listing requirements, including making the required public information available, so each request is complete and accurate. Marketplace listing is completed first, so #THIS ORGANIZATION is listed in the FedRAMP Marketplace before it applies for FedRAMP Certification. #THIS ORGANIZATION submits its own application directly and does not use a third party to apply on its behalf, though third parties may help prepare application and assessment materials.", "#THIS ORGANIZATION identifies a set of information resources to assess for FedRAMP authorization that includes all information resources that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering. This includes configurations and use of third-party information resources. #THIS ORGANIZATION clearly identifies and documents the justification, mitigation measures, compensating controls, and potential impact to federal customer data from the configuration and usage of non-FedRAMP authorized third-party information resources, including metadata (and metadata about federal customer data).\n\n#THIS ORGANIZATION clearly identifies, documents, and explains information flows and impact levels for ALL information resources. Certain categories of cloud computing products and services are specified as entirely outside the scope of FedRAMP by the Director of the Office of Management and Budget. All such products and services are therefore not included in the cloud service offering for FedRAMP. #THIS ORGANIZATION reviews best practices and technical assistance provided separately by FedRAMP for help with applying the Minimum Assessment Scope as needed.\n\nNote: Replace following text and brackets with appropriate validator mention and context.\n\nMinimum Assessment Scope Validators for [Data Wiping Tool] and [Anti-Malware: @Prisma Cloud] ensure all resources are in scope when continuous evidence validations run.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CDS-CSO-UTC", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Liferay SaaS inherits Access Control to Trust Center controls from Paramify Cloud - 20x Moderate.", "Liferay SaaS inherits Documentation on Trust Center controls from Paramify Cloud - 20x Moderate.", "Liferay SaaS inherits FedRAMP-compatible Trust Center controls from Paramify Cloud - 20x Moderate.", "Liferay SaaS inherits Historical Trust Center Data controls from Paramify Cloud - 20x Moderate.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CDS-UTC-AAD", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Customer Admin is responsible for managing account access to their own Liferay SaaS environment and network.", "Liferay SaaS inherits Trust Center Agency Access Management controls from Paramify Cloud - 20x Moderate." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CMU-CSO-CMD", "frrImplementationStatus": "Implemented", "frrImplementation": [ "All services/products within Liferay SaaS use FIPS-validated encryption for customer information in transit and at rest. Authorized validation component details can be found in the Cryptographic Modules Table.", "All authentication mechanisms to cryptographic modules, including those in Liferay SaaS, [Identity Management: @Okta Directory], and [Privileged Access Management: @GCP IAM], use FIPS 140-2 validated AES-256 encryption algorithms. [Operating System: @Google Container Optimized OS running gVisor] crypto modules also use AES-256 and are FIPS validated and listed in the NIST Cryptographic Module Validation Program (CMVP).", "#THIS ORGANIZATION deployed FIPS 140-2 validated modules in all Liferay SaaS components from authorized listing. Change Control Board approval is required for authorized module changes." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CMU-CSO-UVM", "frrImplementationStatus": "Implemented", "frrImplementation": [ "All services/products within Liferay SaaS use FIPS-validated encryption for customer information in transit and at rest. Authorized validation component details can be found in the Cryptographic Modules Table.", "All authentication mechanisms to cryptographic modules, including those in Liferay SaaS, [Identity Management: @Okta Directory], and [Privileged Access Management: @GCP IAM], use FIPS 140-2 validated AES-256 encryption algorithms. [Operating System: @Google Container Optimized OS running gVisor] crypto modules also use AES-256 and are FIPS validated and listed in the NIST Cryptographic Module Validation Program (CMVP)." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC6.1#31: Inspected the encryption configurations for data at rest to determine that passwords and production data was stored in an encrypted format using software supporting the AES.\n\nCC6.6#5: Inspected the encryption configurations and digital certificates to determine that TLS and other encryption technologies were used for defined points of connectivity.\n\nCC6.1#32: Inquired of the Senior Manager, Information Security regarding the encryption keys to determine that encryption keys were required to be protected during generation, storage, use, and destruction.\n\nInspected the encryption policies and procedures and cryptographic keys management software to determine that encryption keys were required to be protected during generation, storage, use, and destruction.\n\n**Result**\n\nCC6.1#31: No exceptions noted.\n\nCC6.6#5: No exceptions noted.\n\nCC6.1#32: No exceptions noted.\n\nNo exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "CPO-CSO-MTD", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Liferay SaaS inherits Certification Data Generation controls from Paramify Cloud - 20x Moderate.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM.", "#THIS ORGANIZATION will notify the @Authorizing Official of significant changes to Liferay SaaS and re-engage the @Auditor to analyze the change. The ISSO will update the security authorization as necessary every three years or for significant changes.\n\nSignificant changes include:\n\n- FIPS 199 category changes,\n\n- hardware/software changes,\n\n- architecture/design changes,\n\n- database architecture changes,\n\n- interconnection changes,\n\n- privileged role changes,\n\n- laws/policies changes,\n\n- authentication/crypto changes, and\n\n- Cloud provider changes\n\nThe ISSO must also communicate changes and testing results to customers as mandated by the @Authorizing Official." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CPO-CSO-OSA", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION will have their goals and validation processes by an independent assessor or FedRAMP directly. This includes assessment of underlying code, pipelines, configurations, automation tools, etc. This assessment includes providing technical explanations, demonstrations, and other relevant supporting information to all necessary assessors. Providers can ask for and accept advice from their assessor during assessment regarding techniques and procedures that will improve their security posture or the effectiveness.\n\nNote: Replace following text and brackets with appropriate validator mention and context.\n\n\\[Independent Assessment : Independent Assessment\\] has an attestation that ensures that the organization grants independent assessors access to [GRC Tool: @Paramify SaaS] for evidence review and actively participates in the assessment by demonstrating underlying code, pipelines, and automation tools." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CPO-CSO-OVR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Liferay SaaS inherits Certification Data Generation controls from Paramify Cloud - 20x Moderate.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "CPO-CSX-CPM", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM.", "#THIS ORGANIZATION will notify the @Authorizing Official of significant changes to Liferay SaaS and re-engage the @Auditor to analyze the change. The ISSO will update the security authorization as necessary every three years or for significant changes.\n\nSignificant changes include:\n\n- FIPS 199 category changes,\n\n- hardware/software changes,\n\n- architecture/design changes,\n\n- database architecture changes,\n\n- interconnection changes,\n\n- privileged role changes,\n\n- laws/policies changes,\n\n- authentication/crypto changes, and\n\n- Cloud provider changes\n\nThe ISSO must also communicate changes and testing results to customers as mandated by the @Authorizing Official." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC4.1#8: Inspected the entity’s policies and procedures review history to determine that management reviewed policies, procedures and other control documents for accuracy and applicability on an annual basis.\n\nCC6.1#6: Inspected the inventory listing of system assets and components to determine that an inventory of system assets and components was maintained to classify and manage the information assets.\n\nCC2.1#2: Inspected the data flow diagrams to determine that data flow diagrams were documented and maintained by management to identify the relevant internal and external information sources of the system.\n\nCC3.4#6: Inspected the risk assessment and management policies and procedures and completed risk assessment to determine that changes to the entity’s systems, applications, technologies, and tools were considered and evaluated as part of the annual comprehensive risk assessment.\n\n**Result**\n\nCC4.1#8: No exceptions noted.\n\nCC6.1#6: No exceptions noted.\n\nCC2.1#2: No exceptions noted.\n\nCC3.4#6: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "FRC-APP-AFC", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Authorizing Official assesses remaining system vulnerabilities and determines risk acceptability for Customer/Agency operations. Based on the accreditation package and consultation, they may issue a provisional accreditation decision with/without restrictions, or not authorize for operation. If restrictions are placed, a detailed POA&M with corrective actions is required for a future updated accreditation package.", "#THIS ORGANIZATION manages a single, owned process for completing and submitting the official FedRAMP forms and packages required to onboard Liferay SaaS to the FedRAMP Marketplace and FedRAMP Certification. The @GRC Admin completes each required FedRAMP form before submission, including the FedRAMP Marketplace Provider Listing Request Form used to request a Marketplace listing (or updates to an existing listing) and the FedRAMP Certification Application Form used to request an initial assessment. Before requesting a listing or an update, #THIS ORGANIZATION addresses the FedRAMP Marketplace listing requirements, including making the required public information available, so each request is complete and accurate. Marketplace listing is completed first, so #THIS ORGANIZATION is listed in the FedRAMP Marketplace before it applies for FedRAMP Certification. #THIS ORGANIZATION submits its own application directly and does not use a third party to apply on its behalf, though third parties may help prepare application and assessment materials.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-APP-FCP", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION manages a single, owned process for completing and submitting the official FedRAMP forms and packages required to onboard Liferay SaaS to the FedRAMP Marketplace and FedRAMP Certification. The @GRC Admin completes each required FedRAMP form before submission, including the FedRAMP Marketplace Provider Listing Request Form used to request a Marketplace listing (or updates to an existing listing) and the FedRAMP Certification Application Form used to request an initial assessment. Before requesting a listing or an update, #THIS ORGANIZATION addresses the FedRAMP Marketplace listing requirements, including making the required public information available, so each request is complete and accurate. Marketplace listing is completed first, so #THIS ORGANIZATION is listed in the FedRAMP Marketplace before it applies for FedRAMP Certification. #THIS ORGANIZATION submits its own application directly and does not use a third party to apply on its behalf, though third parties may help prepare application and assessment materials.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-APP-FIA", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION contracts with @Red Team for annual [Penetration Testing Process: @Penetration Testing Process] of Liferay SaaS.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for the annual [Penetration Testing Process: @Penetration Testing Process] of Liferay SaaS.", "The GRC Admin updates the Security Assessment Plan of Liferay SaaS annually, including security controls and enhancements, assessment procedures, and team roles and responsibilities. The assessment plan is approved by the @Authorizing Official prior to the commencement of the assessment." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-APP-MLF", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Authorizing Official assesses remaining system vulnerabilities and determines risk acceptability for Customer/Agency operations. Based on the accreditation package and consultation, they may issue a provisional accreditation decision with/without restrictions, or not authorize for operation. If restrictions are placed, a detailed POA&M with corrective actions is required for a future updated accreditation package.", "#THIS ORGANIZATION manages a single, owned process for completing and submitting the official FedRAMP forms and packages required to onboard Liferay SaaS to the FedRAMP Marketplace and FedRAMP Certification. The @GRC Admin completes each required FedRAMP form before submission, including the FedRAMP Marketplace Provider Listing Request Form used to request a Marketplace listing (or updates to an existing listing) and the FedRAMP Certification Application Form used to request an initial assessment. Before requesting a listing or an update, #THIS ORGANIZATION addresses the FedRAMP Marketplace listing requirements, including making the required public information available, so each request is complete and accurate. Marketplace listing is completed first, so #THIS ORGANIZATION is listed in the FedRAMP Marketplace before it applies for FedRAMP Certification. #THIS ORGANIZATION submits its own application directly and does not use a third party to apply on its behalf, though third parties may help prepare application and assessment materials.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-APP-NTP", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION manages a single, owned process for completing and submitting the official FedRAMP forms and packages required to onboard Liferay SaaS to the FedRAMP Marketplace and FedRAMP Certification. The @GRC Admin completes each required FedRAMP form before submission, including the FedRAMP Marketplace Provider Listing Request Form used to request a Marketplace listing (or updates to an existing listing) and the FedRAMP Certification Application Form used to request an initial assessment. Before requesting a listing or an update, #THIS ORGANIZATION addresses the FedRAMP Marketplace listing requirements, including making the required public information available, so each request is complete and accurate. Marketplace listing is completed first, so #THIS ORGANIZATION is listed in the FedRAMP Marketplace before it applies for FedRAMP Certification. #THIS ORGANIZATION submits its own application directly and does not use a third party to apply on its behalf, though third parties may help prepare application and assessment materials.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-APP-USA", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The @Auditor conducts annual security assessments for Liferay SaaS, documenting results in a Security Assessment Report (SAR). Confirmed findings are addressed in the [Risk Remediation Process: @Risk Remediation Process] by the GRC Admin.", "The GRC Admin updates the Security Assessment Plan of Liferay SaaS annually, including security controls and enhancements, assessment procedures, and team roles and responsibilities. The assessment plan is approved by the @Authorizing Official prior to the commencement of the assessment." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CLA-ASF", "frrImplementationStatus": "Implemented", "frrImplementation": [ "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nOur examination was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants.\n\n**Result**\n\nthe controls stated in the description operated effectively throughout the period June 1, 2025 to May 31, 2026, to provide reasonable assurance that Liferay’s service commitments and system requirements were achieved based on the applicable Trust Services Criteria, HIPAA/HITECH requirements, and CCM criteria, if complementary subservice organization controls and complementary user entity controls assumed in the design of Liferay’s controls operated effectively throughout that period.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "FRC-CLA-EAM", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The @Auditor conducts annual security assessments for Liferay SaaS, documenting results in a Security Assessment Report (SAR). Confirmed findings are addressed in the [Risk Remediation Process: @Risk Remediation Process] by the GRC Admin.", "The GRC Admin updates the Security Assessment Plan of Liferay SaaS annually, including security controls and enhancements, assessment procedures, and team roles and responsibilities. The assessment plan is approved by the @Authorizing Official prior to the commencement of the assessment." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nOur examination was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants.\n\n**Result**\n\nthe controls stated in the description operated effectively throughout the period June 1, 2025 to May 31, 2026, to provide reasonable assurance that Liferay’s service commitments and system requirements were achieved based on the applicable Trust Services Criteria, HIPAA/HITECH requirements, and CCM criteria, if complementary subservice organization controls and complementary user entity controls assumed in the design of Liferay’s controls operated effectively throughout that period.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "FRC-CLA-IVV", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION contracts with @Red Team for annual [Penetration Testing Process: @Penetration Testing Process] of Liferay SaaS.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for the annual [Penetration Testing Process: @Penetration Testing Process] of Liferay SaaS.", "The GRC Admin updates the Security Assessment Plan of Liferay SaaS annually, including security controls and enhancements, assessment procedures, and team roles and responsibilities. The assessment plan is approved by the @Authorizing Official prior to the commencement of the assessment." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CLA-MFR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The GRC Admin is responsible for managing the development, documentation and dissemination of both [Data Protection Procedures: @Data Protection Procedures] and [Data Protection Policies: @Data Protection Policies].", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CLA-OFR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION publishes an Ongoing Certification Report (OCR) to all necessary parties every 3 months on a regular cycle spread out from a consistent point in each quarter. The OCR covers the entire period since the previous report and includes, at minimum:\n\n- Changes to FedRAMP Certification Data since the last OCR\n- Planned changes to FedRAMP Certification Data for at least the next 3 months\n- Accepted vulnerabilities\n- Transformative changes\n- Updated recommendations or best practices for security, configuration, or usage\n- A list of all agencies directly using the product\n- FedRAMP Reportable Incidents, or an attestation that no such incidents occurred\n- Lessons learned and changes made as a result of any FedRAMP Reportable Incidents\n\nThe target date for the next OCR is published alongside other public FedRAMP Certification Data. Sensitive information that would likely have an adverse effect on Liferay SaaS is not disclosed in the OCR.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CLA-RFR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Machine-based information resources in Liferay SaaS are defined and provisoned through version-controlled infrastrucures-as-code managed in [Code Version Control: @GitHub]. Configuration changes are applied by redeploying version-controlled resources rather than by direct manual modification. Changes are automatically tested and validated through deployment before promotion. The running configuration of deployed resources is persistently compared against the version-controlled definitions to detect drift", "Machine-based information resources in Liferay SaaS are defined and provisoned through version-controlled infrastrucures-as-code managed in [Code Version Control: @GitHub]. Configuration changes are applied by redeploying version-controlled resources rather than by direct manual modification. Changes are automatically tested and validated through deployment before promotion. The running configuration of deployed resources is persistently compared against the version-controlled definitions to detect drift", "The @DevOps Admin maintains a current baseline configuration of Liferay SaaS in [Code Version Control: @GitHub], as outlined in the [Configuration Management Plan: @Configuration Management Plan]. This includes:\n\n- Hardening Liferay SaaS for security while maintaining functionality.\n\n- Enabling only essential ports, protocols, and services.\n\n- Ensuring associated accounts are secure and compliant.\n\n- Disabling non-essential functions, ports, protocols, and services.\n\n- Adhering to the principle of least privilege for device operations and access.\n\nAuthorized personnel approve, test, and deploy any changes to these baselines through the [Change Management Process: @Change Management Process], with updates documented in [System Development Management: @Jira].", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CSO-FCP", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION identifies a set of information resources to assess for FedRAMP authorization that includes all information resources that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering. This includes configurations and use of third-party information resources. #THIS ORGANIZATION clearly identifies and documents the justification, mitigation measures, compensating controls, and potential impact to federal customer data from the configuration and usage of non-FedRAMP authorized third-party information resources, including metadata (and metadata about federal customer data).\n\n#THIS ORGANIZATION clearly identifies, documents, and explains information flows and impact levels for ALL information resources. Certain categories of cloud computing products and services are specified as entirely outside the scope of FedRAMP by the Director of the Office of Management and Budget. All such products and services are therefore not included in the cloud service offering for FedRAMP. #THIS ORGANIZATION reviews best practices and technical assistance provided separately by FedRAMP for help with applying the Minimum Assessment Scope as needed.\n\nNote: Replace following text and brackets with appropriate validator mention and context.\n\nMinimum Assessment Scope Validators for [Data Wiping Tool] and [Anti-Malware: @Prisma Cloud] ensure all resources are in scope when continuous evidence validations run.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CSO-JSN", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Liferay SaaS inherits Certification Data Generation controls from Paramify Cloud - 20x Moderate.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CSO-MRA", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Liferay SaaS inherits Certification Data Generation controls from Paramify Cloud - 20x Moderate.", "#THIS ORGANIZATION publishes an Ongoing Certification Report (OCR) to all necessary parties every 3 months on a regular cycle spread out from a consistent point in each quarter. The OCR covers the entire period since the previous report and includes, at minimum:\n\n- Changes to FedRAMP Certification Data since the last OCR\n- Planned changes to FedRAMP Certification Data for at least the next 3 months\n- Accepted vulnerabilities\n- Transformative changes\n- Updated recommendations or best practices for security, configuration, or usage\n- A list of all agencies directly using the product\n- FedRAMP Reportable Incidents, or an attestation that no such incidents occurred\n- Lessons learned and changes made as a result of any FedRAMP Reportable Incidents\n\nThe target date for the next OCR is published alongside other public FedRAMP Certification Data. Sensitive information that would likely have an adverse effect on Liferay SaaS is not disclosed in the OCR.", "The GRC Admin is responsible for managing the development, documentation and dissemination of both [Data Protection Procedures: @Data Protection Procedures] and [Data Protection Policies: @Data Protection Policies].", "The GRC Admin plans and coordinates security activities with applicable component owners. Activities include:\n\n- vulnerability scanning,\n\n- penetration testing,\n\n- security documentation reviews,\n\n- disaster recovery testing and execution,\n\n- physical and logical access reviews, and\n\n- capacity planning\n\n#THIS ORGANIZATION uses an email distribution list to notify team members involved in these activities.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM.", "The @Customer Admin implements Third-Party Assessment Organization (3PAO) Assessment on Liferay SaaS" ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CSO-PKG", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Authorizing Official assesses remaining system vulnerabilities and determines risk acceptability for Customer/Agency operations. Based on the accreditation package and consultation, they may issue a provisional accreditation decision with/without restrictions, or not authorize for operation. If restrictions are placed, a detailed POA&M with corrective actions is required for a future updated accreditation package.", "Liferay SaaS inherits Certification Data Generation controls from Paramify Cloud - 20x Moderate.", "#THIS ORGANIZATION publishes an Ongoing Certification Report (OCR) to all necessary parties every 3 months on a regular cycle spread out from a consistent point in each quarter. The OCR covers the entire period since the previous report and includes, at minimum:\n\n- Changes to FedRAMP Certification Data since the last OCR\n- Planned changes to FedRAMP Certification Data for at least the next 3 months\n- Accepted vulnerabilities\n- Transformative changes\n- Updated recommendations or best practices for security, configuration, or usage\n- A list of all agencies directly using the product\n- FedRAMP Reportable Incidents, or an attestation that no such incidents occurred\n- Lessons learned and changes made as a result of any FedRAMP Reportable Incidents\n\nThe target date for the next OCR is published alongside other public FedRAMP Certification Data. Sensitive information that would likely have an adverse effect on Liferay SaaS is not disclosed in the OCR.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CSO-POP", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Authorizing Official assesses remaining system vulnerabilities and determines risk acceptability for Customer/Agency operations. Based on the accreditation package and consultation, they may issue a provisional accreditation decision with/without restrictions, or not authorize for operation. If restrictions are placed, a detailed POA&M with corrective actions is required for a future updated accreditation package.", "#THIS ORGANIZATION manages a single, owned process for completing and submitting the official FedRAMP forms and packages required to onboard Liferay SaaS to the FedRAMP Marketplace and FedRAMP Certification. The @GRC Admin completes each required FedRAMP form before submission, including the FedRAMP Marketplace Provider Listing Request Form used to request a Marketplace listing (or updates to an existing listing) and the FedRAMP Certification Application Form used to request an initial assessment. Before requesting a listing or an update, #THIS ORGANIZATION addresses the FedRAMP Marketplace listing requirements, including making the required public information available, so each request is complete and accurate. Marketplace listing is completed first, so #THIS ORGANIZATION is listed in the FedRAMP Marketplace before it applies for FedRAMP Certification. #THIS ORGANIZATION submits its own application directly and does not use a third party to apply on its behalf, though third parties may help prepare application and assessment materials.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CSX-MOT", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION adheres to CR26 FedRAMP 20x Continuous Monitoring frequencies:\n\n- Ongoing monitoring of information system and auditable events, with incident reporting as necessary\n\n- Weekly audit review, analysis and reporting\n\n- Monthly vulnerability scanning, internal reporting of security status, flaw remediation, update of POA&M, and verification of security functions\n\n- Change/refresh authenticators every 60 days\n\n- Quarterly disablement of inactive user accounts\n\n- Annual activities including review and update of security policies and procedures, verification of continued access for account holders, security awareness and training, security assessment by a 3PAO, penetration testing, contingency plan training and testing, incident response training and testing, and review and update of access agreements and rules of behavior\n\n- Prevent reuse of identifiers every two years\n\n- Reauthorize Liferay SaaS every three years, and review and update position categorizations and risk assessments as necessary\n\n- Rescreen personnel every five years." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "FRC-CSX-VVK", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION adheres to CR26 FedRAMP 20x Continuous Monitoring frequencies:\n\n- Ongoing monitoring of information system and auditable events, with incident reporting as necessary\n\n- Weekly audit review, analysis and reporting\n\n- Monthly vulnerability scanning, internal reporting of security status, flaw remediation, update of POA&M, and verification of security functions\n\n- Change/refresh authenticators every 60 days\n\n- Quarterly disablement of inactive user accounts\n\n- Annual activities including review and update of security policies and procedures, verification of continued access for account holders, security awareness and training, security assessment by a 3PAO, penetration testing, contingency plan training and testing, incident response training and testing, and review and update of access agreements and rules of behavior\n\n- Prevent reuse of identifiers every two years\n\n- Reauthorize Liferay SaaS every three years, and review and update position categorizations and risk assessments as necessary\n\n- Rescreen personnel every five years." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC7.1#2: Inspected the monitoring tool configurations, the antivirus software dashboard console, the firewall rulesets for production environments and the IDS configurations to determine that monitoring software was used to identify and evaluate ongoing system performance, capacity, security threats, changing resource utilization needs and usual system activity.\n\nCC4.1#15: Inspected the monitoring tool configurations, an example alert generated from the code repository and an example IDS alert notification to determine that the monitoring software was configured to alert IT personnel when thresholds were exceeded.\n\nCC8.1#3: Inspected the code repository configurations to determine that code repository was utilized to help detect unauthorized changes within the production environment.\n\n**Result**\n\nCC7.1#2: No exceptions noted.\n\nCC4.1#15: No exceptions noted.\n\nCC8.1#3: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "FRC-CSX-VVR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION adheres to CR26 FedRAMP 20x Continuous Monitoring frequencies:\n\n- Ongoing monitoring of information system and auditable events, with incident reporting as necessary\n\n- Weekly audit review, analysis and reporting\n\n- Monthly vulnerability scanning, internal reporting of security status, flaw remediation, update of POA&M, and verification of security functions\n\n- Change/refresh authenticators every 60 days\n\n- Quarterly disablement of inactive user accounts\n\n- Annual activities including review and update of security policies and procedures, verification of continued access for account holders, security awareness and training, security assessment by a 3PAO, penetration testing, contingency plan training and testing, incident response training and testing, and review and update of access agreements and rules of behavior\n\n- Prevent reuse of identifiers every two years\n\n- Reauthorize Liferay SaaS every three years, and review and update position categorizations and risk assessments as necessary\n\n- Rescreen personnel every five years.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "IEC-CSO-DPR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION evaluates, rates, and reports incidents in accordance with FedRAMP Incident Evaluation and Communications rules. The @Incident Response Admin promptly evaluates each incident to determine whether it affects, or is likely to affect, the confidentiality or integrity of federal customer data; such incidents are treated as FedRAMP Reportable Incidents. For each FedRAMP Reportable Incident, #THIS ORGANIZATION promptly estimates the likely adverse impact on agency customers to assign a Potential Agency Impact N-rating (PAIN); until that rating is estimated, the incident is treated as if it has a PAIN rating of 5.\n\n#THIS ORGANIZATION responsibly notifies all affected parties across the incident lifecycle: an Initial Incident Report after identifying a FedRAMP Reportable Incident, Ongoing Incident Reports as new information becomes available during response, and a Final Incident Report once the incident is resolved and recovery is complete. Automation is used where practical to minimize human intervention in reporting to affected parties. Reports are generated in the FedRAMP-defined formats and validated against the corresponding FedRAMP JSON schema where one is provided.", "#THIS ORGANIZATION personnel report suspected or actual security incidents to the Incident Response Admin. #THIS ORGANIZATION also detects potential incidents from sources, including:\n\n- [Security Information and Event Management (SIEM): @Google Security Operations SIEM]\n\n- [Infrastructure Scanning: @Prisma Cloud] Vulnerability Scans\n\n- US-CERT\n\n- Vendor bulletins and reports\n\n@Security Operations Center Admin flags events for the Incident Response Admin to review. The Incident Response Admin creates an incident in [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] after confirming the event is a security incident. The Incident Response Admin analyzes and remediates the incident, documenting each step in the [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] until it is resolved.", "#THIS ORGANIZATION implements an [Incident Response Process: @Incident Response Process] that includes:\n\n- Preparation: Deploying monitoring technology, SIEM, Intrusion Detection, audit logging, automated alerting, and security training\n\n- Identification: Comprehensive logging, monitoring, and automated alerting for anomalies; manual monitoring by trained staff; and creating incident tickets to determine the anomaly's severity rating and best course of action\n\n- Containment: Discovering and defining steps to contain the issue, notifying affected parties via email, and conducting network and endpoint forensics\n\n- Eradication: Assessing actions required for long-term and/or permanent changes to prevent the issue from occurring again\n\n- Recovery: Restoring impacted systems, services, or functions to a full and secure operational status, with formal approval from the @Operations Admin and the @ISSO\n\n- Lessons Learned: Collecting all notes and documents to identify opportunities to improve the [Incident Response Process: @Incident Response Process].", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan" ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "IEC-CSO-EFI", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION evaluates, rates, and reports incidents in accordance with FedRAMP Incident Evaluation and Communications rules. The @Incident Response Admin promptly evaluates each incident to determine whether it affects, or is likely to affect, the confidentiality or integrity of federal customer data; such incidents are treated as FedRAMP Reportable Incidents. For each FedRAMP Reportable Incident, #THIS ORGANIZATION promptly estimates the likely adverse impact on agency customers to assign a Potential Agency Impact N-rating (PAIN); until that rating is estimated, the incident is treated as if it has a PAIN rating of 5.\n\n#THIS ORGANIZATION responsibly notifies all affected parties across the incident lifecycle: an Initial Incident Report after identifying a FedRAMP Reportable Incident, Ongoing Incident Reports as new information becomes available during response, and a Final Incident Report once the incident is resolved and recovery is complete. Automation is used where practical to minimize human intervention in reporting to affected parties. Reports are generated in the FedRAMP-defined formats and validated against the corresponding FedRAMP JSON schema where one is provided.", "#THIS ORGANIZATION personnel report suspected or actual security incidents to the Incident Response Admin. #THIS ORGANIZATION also detects potential incidents from sources, including:\n\n- [Security Information and Event Management (SIEM): @Google Security Operations SIEM]\n\n- [Infrastructure Scanning: @Prisma Cloud] Vulnerability Scans\n\n- US-CERT\n\n- Vendor bulletins and reports\n\n@Security Operations Center Admin flags events for the Incident Response Admin to review. The Incident Response Admin creates an incident in [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] after confirming the event is a security incident. The Incident Response Admin analyzes and remediates the incident, documenting each step in the [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] until it is resolved.", "#THIS ORGANIZATION implements an [Incident Response Process: @Incident Response Process] that includes:\n\n- Preparation: Deploying monitoring technology, SIEM, Intrusion Detection, audit logging, automated alerting, and security training\n\n- Identification: Comprehensive logging, monitoring, and automated alerting for anomalies; manual monitoring by trained staff; and creating incident tickets to determine the anomaly's severity rating and best course of action\n\n- Containment: Discovering and defining steps to contain the issue, notifying affected parties via email, and conducting network and endpoint forensics\n\n- Eradication: Assessing actions required for long-term and/or permanent changes to prevent the issue from occurring again\n\n- Recovery: Restoring impacted systems, services, or functions to a full and secure operational status, with formal approval from the @Operations Admin and the @ISSO\n\n- Lessons Learned: Collecting all notes and documents to identify opportunities to improve the [Incident Response Process: @Incident Response Process].", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan" ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "IEC-CSO-EFR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION evaluates, rates, and reports incidents in accordance with FedRAMP Incident Evaluation and Communications rules. The @Incident Response Admin promptly evaluates each incident to determine whether it affects, or is likely to affect, the confidentiality or integrity of federal customer data; such incidents are treated as FedRAMP Reportable Incidents. For each FedRAMP Reportable Incident, #THIS ORGANIZATION promptly estimates the likely adverse impact on agency customers to assign a Potential Agency Impact N-rating (PAIN); until that rating is estimated, the incident is treated as if it has a PAIN rating of 5.\n\n#THIS ORGANIZATION responsibly notifies all affected parties across the incident lifecycle: an Initial Incident Report after identifying a FedRAMP Reportable Incident, Ongoing Incident Reports as new information becomes available during response, and a Final Incident Report once the incident is resolved and recovery is complete. Automation is used where practical to minimize human intervention in reporting to affected parties. Reports are generated in the FedRAMP-defined formats and validated against the corresponding FedRAMP JSON schema where one is provided.", "#THIS ORGANIZATION personnel report suspected or actual security incidents to the Incident Response Admin. #THIS ORGANIZATION also detects potential incidents from sources, including:\n\n- [Security Information and Event Management (SIEM): @Google Security Operations SIEM]\n\n- [Infrastructure Scanning: @Prisma Cloud] Vulnerability Scans\n\n- US-CERT\n\n- Vendor bulletins and reports\n\n@Security Operations Center Admin flags events for the Incident Response Admin to review. The Incident Response Admin creates an incident in [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] after confirming the event is a security incident. The Incident Response Admin analyzes and remediates the incident, documenting each step in the [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] until it is resolved.", "#THIS ORGANIZATION implements an [Incident Response Process: @Incident Response Process] that includes:\n\n- Preparation: Deploying monitoring technology, SIEM, Intrusion Detection, audit logging, automated alerting, and security training\n\n- Identification: Comprehensive logging, monitoring, and automated alerting for anomalies; manual monitoring by trained staff; and creating incident tickets to determine the anomaly's severity rating and best course of action\n\n- Containment: Discovering and defining steps to contain the issue, notifying affected parties via email, and conducting network and endpoint forensics\n\n- Eradication: Assessing actions required for long-term and/or permanent changes to prevent the issue from occurring again\n\n- Recovery: Restoring impacted systems, services, or functions to a full and secure operational status, with formal approval from the @Operations Admin and the @ISSO\n\n- Lessons Learned: Collecting all notes and documents to identify opportunities to improve the [Incident Response Process: @Incident Response Process].", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan", "If an information spill occurs within Liferay SaaS, the Incident Response Admin follows the [Incident Response Plan: @Incident Response Plan] to contain the incident.\n\nThe Incident Response Admin coordinates with relevant business units to determine who will investigate and remediate the incident. They triage affected components, assess eradication steps, and investigate possible replication of data in other areas. #THIS ORGANIZATION provides annual information spillage training and conducts tabletop exercises.\n\nThe Incident Response Admin is the point of contact for reporting security incidents, including information spills, via phone, email, or via [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM]." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC7.3#1: Inquired of the Senior Manager, Information Security regarding incident management to determine that identified incidents were analyzed, classified, and prioritized based on system impact to determine the appropriate containment strategy, including a determination of the appropriate response time frame and the determination and execution of the containment approach.\n\nInspected the incident response and notification procedure to determine that identified incidents were analyzed, classified, and prioritized based on system impact to determine the appropriate containment strategy, including a determination of the appropriate response time frame and the determination and execution of the containment approach.\n\nInspected the supporting incident ticket for a sample of incidents to determine that identified incidents were analyzed, classified, and prioritized based on system impact to determine the appropriate containment strategy, including a determination of the appropriate response time frame and the determination and execution of the containment approach.\n\nCC7.3#4: Inspected the incident response policies and procedures to determine that the incident response policies and procedures defined the classification of incidents based on its severity.\n\nCC7.3#8: Inspected the supporting incident ticket for a sample of incidents to determine that identified incidents were reviewed, monitored and investigated by an incident response team.\n\n**Result**\n\nCC7.3#1: No exceptions noted.\n\nNo exceptions noted.\n\nNo exceptions noted.\n\nCC7.3#4: No exceptions noted.\n\nCC7.3#8: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "IEC-CSO-FIR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION evaluates, rates, and reports incidents in accordance with FedRAMP Incident Evaluation and Communications rules. The @Incident Response Admin promptly evaluates each incident to determine whether it affects, or is likely to affect, the confidentiality or integrity of federal customer data; such incidents are treated as FedRAMP Reportable Incidents. For each FedRAMP Reportable Incident, #THIS ORGANIZATION promptly estimates the likely adverse impact on agency customers to assign a Potential Agency Impact N-rating (PAIN); until that rating is estimated, the incident is treated as if it has a PAIN rating of 5.\n\n#THIS ORGANIZATION responsibly notifies all affected parties across the incident lifecycle: an Initial Incident Report after identifying a FedRAMP Reportable Incident, Ongoing Incident Reports as new information becomes available during response, and a Final Incident Report once the incident is resolved and recovery is complete. Automation is used where practical to minimize human intervention in reporting to affected parties. Reports are generated in the FedRAMP-defined formats and validated against the corresponding FedRAMP JSON schema where one is provided.", "#THIS ORGANIZATION reports incidents to Federal stakeholders in the following ways:\n\n| To | Within | By |\n| --- | --- | --- |\n| FedRAMP | 1 hour of identification | Sending an email to fedramp\\_security@fedramp.gov |\n| All agency customers | 1 hour of identification | The incident communications points of contact provided by each agency customer |\n| CISA | 1 hour of identificationIf the incident is confirmed or suspected to be result of an attack vector listed at [https://www.cisa.gov/federal-incident-notification-guidelines#attack-vectors-taxonomy](https://www.cisa.gov/federal-incident-notification-guidelines#attack-vectors-taxonomy) | Using the CISA Incident Reporting System at: [https://myservices.cisa.gov/irf](https://myservices.cisa.gov/irf) |\n\nOnce initially notified, the Incident Response Admin updates all necessary parties once per calendar day until the incident is resolved and recovery is complete.\n\nThe Incident Response Admin makes incident report information available in #THIS ORGANIZATION's [Trust Center: @Paramify Cloud - 20x Moderate] without irresponsibly disclosing specific information about the incident that would increase the impact of the incident.\n\nOnce the incident is resolved, the Incident Response Admin provides a final report which describes details about what occurred and why, as well as what the incident response methods were and how those could be improved upon for the future. The final incident report is provided in a human-readable and machine-readable format.\n\n\\[Incident Communications Procedures : Incident Communications Procedures\\] has an attestation that ensures that the Incident Response Admin ensures all personnel receive incident response training (covering roles and responsibilities) within 90 days of hire and annually thereafter.", "The Incident Response Admin manages [Incident Response Plan: @Incident Response Plan] and updates the plan at least annually to ensure the [Incident Response Process: @Incident Response Process] is consistently applied across the #THIS ORGANIZATION. Changes to Liferay SaaS affecting the [Incident Response Plan: @Incident Response Plan] are included in updates, which also address concerns or difficulties during implementation, execution, or testing.\n\nTo better ensure the [Incident Response Plan: @Incident Response Plan] is helping meet #THIS ORGANIZATION incident response objectives, the Incident Response Admin reviews these key metrics:\n\n- Number of alerts fired over x days\n\n- Number of requests received over x days\n\n- Number of investigations conducted over x days\n\n- Number of alerts closed over x days\n\n- Number of requests closed over x days\n\n- Number of investigations closed over x days\n\n- Number of hours spent on alerts, requests, and investigations\n\n- Number of tickets assigned by type and source\n\n- Number of discovery tickets created, closed\n\n- Number of false positive alerts over time, by type\n\n- Tickets closed per Affected User Department\n\n- Mean Time to Respond\n\n- Mean Time to Resolve\n\n- Mean Time to Close", "The Incident Response Admin documents incident handling lessons learned in [File Storage: @Google Drive] to update response procedures, training and testing/exercises. Notes and documents are compiled to review incident timeline and actions, identify weaknesses, gaps, and inefficiencies. Improvement techniques are implemented, and recommendations are made with action items assigned to key stakeholders.", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan", "Liferay SaaS uses Google Security Operations SIEM, a component of GCP, to implement Incident Response Tracking controls.", "Once a security incident is identified, the Incident Response Admin creates a ticket in [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] to document and track the incident. After the ticket is created, the Incident Response Admin collaborates with the @DevOps Admin to analyze the incident and determine the necessary remediation actions. The Incident Response Admin works with applicable teams to fix the issue. Each step taken during the analysis and [Risk Remediation Process: @Risk Remediation Process] is documented in the [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] ticket until the incident has been resolved." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC7.4#12: Inquired of the Senior Manager, Information Security regarding incident management to determine that critical security incidents that result in a service/business operation disruption were communicated to those affected through creation of an incident postmortem.\n\nInspected the incident response and notification procedure to determine that critical security incidents that result in a service/business operation disruption were communicated to those affected through creation of an incident postmortem.\n\nInspected the supporting incident ticket for a sample of critical incidents to determine that critical security incidents that result in a service/business operation disruption were communicated to those affected through creation of an incident postmortem.\n\nCC7.4#10: Inspected the supporting incident ticket for a sample of incidents to determine that the actions taken to address identified security incidents were documented and communicated to affected parties.\n\nCC7.3#5: Inspected the supporting incident ticket for a sample of incidents to determine that resolution of incidents was documented within the ticket and communicated to affected users.\n\nCC7.4#13: Inspected the supporting incident ticket for a sample of incidents to determine that the remediation actions taken for security incidents were documented within the ticket and communicated to affected users.\n\n**Result**\n\nCC7.4#12: No exceptions noted.\n\nNo exceptions noted.\n\nTesting of the control activity disclosed that there were no critical incidents identified during the review period.\n\nCC7.4#10: No exceptions noted.\n\nCC7.3#5: No exceptions noted.\n\nCC7.4#13: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "IEC-CSO-IIR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION evaluates, rates, and reports incidents in accordance with FedRAMP Incident Evaluation and Communications rules. The @Incident Response Admin promptly evaluates each incident to determine whether it affects, or is likely to affect, the confidentiality or integrity of federal customer data; such incidents are treated as FedRAMP Reportable Incidents. For each FedRAMP Reportable Incident, #THIS ORGANIZATION promptly estimates the likely adverse impact on agency customers to assign a Potential Agency Impact N-rating (PAIN); until that rating is estimated, the incident is treated as if it has a PAIN rating of 5.\n\n#THIS ORGANIZATION responsibly notifies all affected parties across the incident lifecycle: an Initial Incident Report after identifying a FedRAMP Reportable Incident, Ongoing Incident Reports as new information becomes available during response, and a Final Incident Report once the incident is resolved and recovery is complete. Automation is used where practical to minimize human intervention in reporting to affected parties. Reports are generated in the FedRAMP-defined formats and validated against the corresponding FedRAMP JSON schema where one is provided.", "#THIS ORGANIZATION reports incidents to Federal stakeholders in the following ways:\n\n| To | Within | By |\n| --- | --- | --- |\n| FedRAMP | 1 hour of identification | Sending an email to fedramp\\_security@fedramp.gov |\n| All agency customers | 1 hour of identification | The incident communications points of contact provided by each agency customer |\n| CISA | 1 hour of identificationIf the incident is confirmed or suspected to be result of an attack vector listed at [https://www.cisa.gov/federal-incident-notification-guidelines#attack-vectors-taxonomy](https://www.cisa.gov/federal-incident-notification-guidelines#attack-vectors-taxonomy) | Using the CISA Incident Reporting System at: [https://myservices.cisa.gov/irf](https://myservices.cisa.gov/irf) |\n\nOnce initially notified, the Incident Response Admin updates all necessary parties once per calendar day until the incident is resolved and recovery is complete.\n\nThe Incident Response Admin makes incident report information available in #THIS ORGANIZATION's [Trust Center: @Paramify Cloud - 20x Moderate] without irresponsibly disclosing specific information about the incident that would increase the impact of the incident.\n\nOnce the incident is resolved, the Incident Response Admin provides a final report which describes details about what occurred and why, as well as what the incident response methods were and how those could be improved upon for the future. The final incident report is provided in a human-readable and machine-readable format.\n\n\\[Incident Communications Procedures : Incident Communications Procedures\\] has an attestation that ensures that the Incident Response Admin ensures all personnel receive incident response training (covering roles and responsibilities) within 90 days of hire and annually thereafter.", "#THIS ORGANIZATION personnel report suspected or actual security incidents to the Incident Response Admin. #THIS ORGANIZATION also detects potential incidents from sources, including:\n\n- [Security Information and Event Management (SIEM): @Google Security Operations SIEM]\n\n- [Infrastructure Scanning: @Prisma Cloud] Vulnerability Scans\n\n- US-CERT\n\n- Vendor bulletins and reports\n\n@Security Operations Center Admin flags events for the Incident Response Admin to review. The Incident Response Admin creates an incident in [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] after confirming the event is a security incident. The Incident Response Admin analyzes and remediates the incident, documenting each step in the [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] until it is resolved.", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan", "Liferay SaaS uses Google Security Operations SIEM, a component of GCP, to implement Incident Response Tracking controls.", "Once a security incident is identified, the Incident Response Admin creates a ticket in [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] to document and track the incident. After the ticket is created, the Incident Response Admin collaborates with the @DevOps Admin to analyze the incident and determine the necessary remediation actions. The Incident Response Admin works with applicable teams to fix the issue. Each step taken during the analysis and [Risk Remediation Process: @Risk Remediation Process] is documented in the [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] ticket until the incident has been resolved." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC7.3#9: Inquired of the Senior Manager, Information Security regarding incident management to determine that incidents resulting in the unauthorized use or disclosure of personal information were communicated to the affected users.\n\nInspected the incident response and notification procedure to determine that incidents resulting in the unauthorized use or disclosure of personal information were communicated to the affected users.\n\nInspected the incident ticket for a sample of critical incidents that resulted in unauthorized disclosure of personal information to determine that incidents resulting in the unauthorized use or disclosure of personal information were identified and communicated to the affected users.\n\nCC7.4#10: Inspected the supporting incident ticket for a sample of incidents to determine that the actions taken to address identified security incidents were documented and communicated to affected parties.\n\n**Result**\n\nCC7.3#9: No exceptions noted.\n\nNo exceptions noted.\n\nTesting of the control activity disclosed that there were no critical incidents identified that resulted in the unauthorized use or disclosure of personal information during the review period.\n\nCC7.4#10: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "IEC-CSO-OIR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION evaluates, rates, and reports incidents in accordance with FedRAMP Incident Evaluation and Communications rules. The @Incident Response Admin promptly evaluates each incident to determine whether it affects, or is likely to affect, the confidentiality or integrity of federal customer data; such incidents are treated as FedRAMP Reportable Incidents. For each FedRAMP Reportable Incident, #THIS ORGANIZATION promptly estimates the likely adverse impact on agency customers to assign a Potential Agency Impact N-rating (PAIN); until that rating is estimated, the incident is treated as if it has a PAIN rating of 5.\n\n#THIS ORGANIZATION responsibly notifies all affected parties across the incident lifecycle: an Initial Incident Report after identifying a FedRAMP Reportable Incident, Ongoing Incident Reports as new information becomes available during response, and a Final Incident Report once the incident is resolved and recovery is complete. Automation is used where practical to minimize human intervention in reporting to affected parties. Reports are generated in the FedRAMP-defined formats and validated against the corresponding FedRAMP JSON schema where one is provided.", "#THIS ORGANIZATION reports incidents to Federal stakeholders in the following ways:\n\n| To | Within | By |\n| --- | --- | --- |\n| FedRAMP | 1 hour of identification | Sending an email to fedramp\\_security@fedramp.gov |\n| All agency customers | 1 hour of identification | The incident communications points of contact provided by each agency customer |\n| CISA | 1 hour of identificationIf the incident is confirmed or suspected to be result of an attack vector listed at [https://www.cisa.gov/federal-incident-notification-guidelines#attack-vectors-taxonomy](https://www.cisa.gov/federal-incident-notification-guidelines#attack-vectors-taxonomy) | Using the CISA Incident Reporting System at: [https://myservices.cisa.gov/irf](https://myservices.cisa.gov/irf) |\n\nOnce initially notified, the Incident Response Admin updates all necessary parties once per calendar day until the incident is resolved and recovery is complete.\n\nThe Incident Response Admin makes incident report information available in #THIS ORGANIZATION's [Trust Center: @Paramify Cloud - 20x Moderate] without irresponsibly disclosing specific information about the incident that would increase the impact of the incident.\n\nOnce the incident is resolved, the Incident Response Admin provides a final report which describes details about what occurred and why, as well as what the incident response methods were and how those could be improved upon for the future. The final incident report is provided in a human-readable and machine-readable format.\n\n\\[Incident Communications Procedures : Incident Communications Procedures\\] has an attestation that ensures that the Incident Response Admin ensures all personnel receive incident response training (covering roles and responsibilities) within 90 days of hire and annually thereafter.", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan", "Liferay SaaS uses Google Security Operations SIEM, a component of GCP, to implement Incident Response Tracking controls.", "Once a security incident is identified, the Incident Response Admin creates a ticket in [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] to document and track the incident. After the ticket is created, the Incident Response Admin collaborates with the @DevOps Admin to analyze the incident and determine the necessary remediation actions. The Incident Response Admin works with applicable teams to fix the issue. Each step taken during the analysis and [Risk Remediation Process: @Risk Remediation Process] is documented in the [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] ticket until the incident has been resolved." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC7.4#13: Inspected the supporting incident ticket for a sample of incidents to determine that the remediation actions taken for security incidents were documented within the ticket and communicated to affected users.\n\nCC7.3#6: Inspected the supporting incident ticket for a sample of incidents to determine that incidents were documented and tracked in a standardized ticketing system and updated to reflect the planned incident and problem resolution.\n\nCC7.4#8: Inquired of the Senior Manager, Information Security regarding incident management to determine that a security incident analysis was performed for critical incidents to determine the root cause, system impact and resolution.\n\nInspected the incident response and notification procedure to determine that a security incident analysis was performed for critical incidents to determine the root cause, system impact and resolution.\n\nInspected the supporting incident ticket for a sample of critical incidents to determine that a security incident analysis was performed for critical incidents to determine the root cause, system impact and resolution.\n\n**Result**\n\nCC7.4#13: No exceptions noted.\n\nCC7.3#6: No exceptions noted.\n\nCC7.4#8: No exceptions noted.\n\nNo exceptions noted.\n\nTesting of the control activity disclosed that there were no critical incidents identified during the review period.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "IVV-CSO-FIA", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION contracts with @Red Team for annual [Penetration Testing Process: @Penetration Testing Process] of Liferay SaaS.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for the annual [Penetration Testing Process: @Penetration Testing Process] of Liferay SaaS.", "The GRC Admin updates the Security Assessment Plan of Liferay SaaS annually, including security controls and enhancements, assessment procedures, and team roles and responsibilities. The assessment plan is approved by the @Authorizing Official prior to the commencement of the assessment.", "The @Customer Admin implements Third-Party Assessment Organization (3PAO) Assessment on Liferay SaaS" ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "IVV-CSO-ICP", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Liferay SaaS inherits Certification Data Generation controls from Paramify Cloud - 20x Moderate.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM.", "The @Customer Admin implements Third-Party Assessment Organization (3PAO) Assessment on Liferay SaaS" ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "IVV-CSX-AIA", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION will have their goals and validation processes by an independent assessor or FedRAMP directly. This includes assessment of underlying code, pipelines, configurations, automation tools, etc. This assessment includes providing technical explanations, demonstrations, and other relevant supporting information to all necessary assessors. Providers can ask for and accept advice from their assessor during assessment regarding techniques and procedures that will improve their security posture or the effectiveness.\n\nNote: Replace following text and brackets with appropriate validator mention and context.\n\n\\[Independent Assessment : Independent Assessment\\] has an attestation that ensures that the organization grants independent assessors access to [GRC Tool: @Paramify SaaS] for evidence review and actively participates in the assessment by demonstrating underlying code, pipelines, and automation tools.", "#THIS ORGANIZATION contracts with @Red Team for annual [Penetration Testing Process: @Penetration Testing Process] of Liferay SaaS.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for the annual [Penetration Testing Process: @Penetration Testing Process] of Liferay SaaS.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for annual vulnerability scanning and penetration testing of the Liferay SaaS environment.\n\nMonthly vulnerability scanning is performed by #THIS ORGANIZATION for:\n\n- Servers: [Infrastructure Scanning: @Prisma Cloud]\n\n- Containers: [Container Scanning: @Prisma Cloud]\n\n- Databases: [Infrastructure Scanning: @Prisma Cloud]\n\n- Web: [Application Scanning: @Prisma Cloud]\n\nThe POA&M document is updated monthly with remediation activities for any high, moderate, or low-risk vulnerabilities identified in ongoing assessments and scans. Raw scan reports are made available to @Authorizing Official monthly." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nOur examination was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants.\n\n**Result**\n\nthe controls stated in the description operated effectively throughout the period June 1, 2025 to May 31, 2026, to provide reasonable assurance that Liferay’s service commitments and system requirements were achieved based on the applicable Trust Services Criteria, HIPAA/HITECH requirements, and CCM criteria, if complementary subservice organization controls and complementary user entity controls assumed in the design of Liferay’s controls operated effectively throughout that period.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "MAS-CSO-FLO", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Change Control Board reviews and approves the data inventory at least annually or whenever significant changes to Liferay SaaS occur. This process identifies which data types are stored and processed within Liferay SaaS, their respective components, the protection measures in place for each data type, and the roles authorized to access them. The data inventory is maintained in [Compliance Deliverables Management: @Paramify SaaS].", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "MAS-CSO-IIR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Change Control Board reviews and approves the data inventory at least annually or whenever significant changes to Liferay SaaS occur. This process identifies which data types are stored and processed within Liferay SaaS, their respective components, the protection measures in place for each data type, and the roles authorized to access them. The data inventory is maintained in [Compliance Deliverables Management: @Paramify SaaS].", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC6.1#6: Inspected the inventory listing of system assets and components to determine that an inventory of system assets and components was maintained to classify and manage the information assets.\n\nCC2.1#2: Inspected the data flow diagrams to determine that data flow diagrams were documented and maintained by management to identify the relevant internal and external information sources of the system.\n\nC1.2#2: Inspected the asset inventory to determine that an inventory was maintained of assets with confidential data, and as confidential data met the retention period, the data was destroyed or purged.\n\n**Result**\n\nCC6.1#6: No exceptions noted.\n\nCC2.1#2: No exceptions noted.\n\nC1.2#2: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "MAS-CSO-TPR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The @Operations Admin oversees acquisition of external services. The @DevOps Admin defines functional requirements and engages @Operations Admin for product acquisition. The @GRC Admin conducts risk assessment prior to acquisition to ensure compliance with Liferay SaaS security controls.", "The Vendor Risk Management Admin ensures #THIS ORGANIZATION has SLAs with each Cloud Service Provider (CSP) as part of [Vendor Risk Management Process: @Vendor Risk Management Process], consistent with data protection requirements and processing agreements.", "The Vendor Risk Management Admin annually reviews third-party assurance reports of vendors hosting customer data to ensure compliance with #THIS ORGANIZATION security requirements, including contingency requirements in [Vendor Management: @Priverion]. If gaps are found, management takes action to address their impact." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "MKT-CSO-MLR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Authorizing Official assesses remaining system vulnerabilities and determines risk acceptability for Customer/Agency operations. Based on the accreditation package and consultation, they may issue a provisional accreditation decision with/without restrictions, or not authorize for operation. If restrictions are placed, a detailed POA&M with corrective actions is required for a future updated accreditation package.", "Liferay SaaS inherits Documentation on Trust Center controls from Paramify Cloud - 20x Moderate.", "#THIS ORGANIZATION manages a single, owned process for completing and submitting the official FedRAMP forms and packages required to onboard Liferay SaaS to the FedRAMP Marketplace and FedRAMP Certification. The @GRC Admin completes each required FedRAMP form before submission, including the FedRAMP Marketplace Provider Listing Request Form used to request a Marketplace listing (or updates to an existing listing) and the FedRAMP Certification Application Form used to request an initial assessment. Before requesting a listing or an update, #THIS ORGANIZATION addresses the FedRAMP Marketplace listing requirements, including making the required public information available, so each request is complete and accurate. Marketplace listing is completed first, so #THIS ORGANIZATION is listed in the FedRAMP Marketplace before it applies for FedRAMP Certification. #THIS ORGANIZATION submits its own application directly and does not use a third party to apply on its behalf, though third parties may help prepare application and assessment materials.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "MKT-CSO-PML", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Authorizing Official assesses remaining system vulnerabilities and determines risk acceptability for Customer/Agency operations. Based on the accreditation package and consultation, they may issue a provisional accreditation decision with/without restrictions, or not authorize for operation. If restrictions are placed, a detailed POA&M with corrective actions is required for a future updated accreditation package.", "#THIS ORGANIZATION manages a single, owned process for completing and submitting the official FedRAMP forms and packages required to onboard Liferay SaaS to the FedRAMP Marketplace and FedRAMP Certification. The @GRC Admin completes each required FedRAMP form before submission, including the FedRAMP Marketplace Provider Listing Request Form used to request a Marketplace listing (or updates to an existing listing) and the FedRAMP Certification Application Form used to request an initial assessment. Before requesting a listing or an update, #THIS ORGANIZATION addresses the FedRAMP Marketplace listing requirements, including making the required public information available, so each request is complete and accurate. Marketplace listing is completed first, so #THIS ORGANIZATION is listed in the FedRAMP Marketplace before it applies for FedRAMP Certification. #THIS ORGANIZATION submits its own application directly and does not use a third party to apply on its behalf, though third parties may help prepare application and assessment materials.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "MKT-IIP-AGU", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The Authorizing Official assesses remaining system vulnerabilities and determines risk acceptability for Customer/Agency operations. Based on the accreditation package and consultation, they may issue a provisional accreditation decision with/without restrictions, or not authorize for operation. If restrictions are placed, a detailed POA&M with corrective actions is required for a future updated accreditation package.", "#THIS ORGANIZATION establishes that the offering belongs in FedRAMP and is on a credible, time-bound path to certification. The @GRC Admin demonstrates a qualifying federal agency use case for the offering and commits it to a concrete assessment timeline, so its place in the Initial Implementation Phase is justified and clearly headed toward a full certification rather than lingering indefinitely.", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "MKT-IIP-DCP", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION adheres to CR26 FedRAMP 20x Continuous Monitoring frequencies:\n\n- Ongoing monitoring of information system and auditable events, with incident reporting as necessary\n\n- Weekly audit review, analysis and reporting\n\n- Monthly vulnerability scanning, internal reporting of security status, flaw remediation, update of POA&M, and verification of security functions\n\n- Change/refresh authenticators every 60 days\n\n- Quarterly disablement of inactive user accounts\n\n- Annual activities including review and update of security policies and procedures, verification of continued access for account holders, security awareness and training, security assessment by a 3PAO, penetration testing, contingency plan training and testing, incident response training and testing, and review and update of access agreements and rules of behavior\n\n- Prevent reuse of identifiers every two years\n\n- Reauthorize Liferay SaaS every three years, and review and update position categorizations and risk assessments as necessary\n\n- Rescreen personnel every five years.", "Liferay SaaS inherits FedRAMP-compatible Trust Center controls from Paramify Cloud - 20x Moderate." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "MKT-IIP-DLA", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION establishes that the offering belongs in FedRAMP and is on a credible, time-bound path to certification. The @GRC Admin demonstrates a qualifying federal agency use case for the offering and commits it to a concrete assessment timeline, so its place in the Initial Implementation Phase is justified and clearly headed toward a full certification rather than lingering indefinitely.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for the annual [Penetration Testing Process: @Penetration Testing Process] of Liferay SaaS.", "The GRC Admin updates the Security Assessment Plan of Liferay SaaS annually, including security controls and enhancements, assessment procedures, and team roles and responsibilities. The assessment plan is approved by the @Authorizing Official prior to the commencement of the assessment." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "SDR-CSO-FRR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Liferay SaaS inherits Certification Data Generation controls from Paramify Cloud - 20x Moderate.", "The GRC Admin is responsible for managing the development, documentation and dissemination of both [Data Protection Procedures: @Data Protection Procedures] and [Data Protection Policies: @Data Protection Policies].", "For security authorization, the @Authorizing Official reviews the security authorization package to determine if identified vulnerabilities pose an acceptable risk. Authority to Operate (ATO) is granted after balancing security considerations with mission needs. Authorization package provides essential information for a credible risk-based decision.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "SDR-CSX-KMT", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "#THIS ORGANIZATION adheres to CR26 FedRAMP 20x Continuous Monitoring frequencies:\n\n- Ongoing monitoring of information system and auditable events, with incident reporting as necessary\n\n- Weekly audit review, analysis and reporting\n\n- Monthly vulnerability scanning, internal reporting of security status, flaw remediation, update of POA&M, and verification of security functions\n\n- Change/refresh authenticators every 60 days\n\n- Quarterly disablement of inactive user accounts\n\n- Annual activities including review and update of security policies and procedures, verification of continued access for account holders, security awareness and training, security assessment by a 3PAO, penetration testing, contingency plan training and testing, incident response training and testing, and review and update of access agreements and rules of behavior\n\n- Prevent reuse of identifiers every two years\n\n- Reauthorize Liferay SaaS every three years, and review and update position categorizations and risk assessments as necessary\n\n- Rescreen personnel every five years.", "#THIS ORGANIZATION developed a [System Security Plan: @System Security Plan] for Liferay SaaS consistent with the enterprise architecture. It defines:\n\n- authorization boundary and operational context,\n\n- security categorization of the system,\n\n- outline of the technical environment, control requirements, and rationale tailoring decisions.\n\nThe [System Security Plan: @System Security Plan] requires review and approval by @ISSO and @ISSM." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "VDR-CSO-DET", "frrImplementationStatus": "Implemented", "frrImplementation": [ "During development and testing, the DevOps Admin and @Developer analyze builds for vulnerabilities using [Code Scanning: @Xbow]. Security flaws trigger a ticket in [System Development Management: @Jira] for the @Developer to fix. Only approved builds move to production. Remediation progress is monitored by the DevOps Admin.", "The InfoSec Admin establishes a channel for receiving public vulnerability reports for relevant components within Liferay SaaS.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for annual vulnerability scanning and penetration testing of the Liferay SaaS environment.\n\nMonthly vulnerability scanning is performed by #THIS ORGANIZATION for:\n\n- Servers: [Infrastructure Scanning: @Prisma Cloud]\n\n- Containers: [Container Scanning: @Prisma Cloud]\n\n- Databases: [Infrastructure Scanning: @Prisma Cloud]\n\n- Web: [Application Scanning: @Prisma Cloud]\n\nThe POA&M document is updated monthly with remediation activities for any high, moderate, or low-risk vulnerabilities identified in ongoing assessments and scans. Raw scan reports are made available to @Authorizing Official monthly.", "The InfoSec Admin manages the timely resolution of vulnerabilities, categorized by severity:\n\n- Critical-risk: within 2 days,\n\n- High-risk: within 30 days,\n\n- Moderate-risk: within 90 days,\n\n- Low-risk: within 180 days.\n\nVulnerabilities are logged, assigned to respective component owners, and tracked to resolution in [IT Service Management: @Jira Service Management]." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC7.1#3: Inspected the vulnerability scanning policies and procedures, the completed vulnerability scan results and the associated resolution documentation for a sample of identified vulnerabilities to determine that vulnerability scans were performed annually and remedial actions were taken where necessary.\n\nCC4.1#12: Inspected the completed penetration test results and the supporting incident ticket for a sample of vulnerabilities identified from vulnerability scans or penetration tests to determine that a third-party performed penetration testing annually to identify and exploit vulnerabilities identified within the environment, and identified vulnerabilities were addressed and tracked to resolution.\n\nCC6.6#10: Inspected the network diagram and IDS configurations to determine that an IDS was utilized to analyze network events and report possible or actual network security breaches.\n\nCC7.1#2: Inspected the monitoring tool configurations, the antivirus software dashboard console, the firewall rulesets for production environments and the IDS configurations to determine that monitoring software was used to identify and evaluate ongoing system performance, capacity, security threats, changing resource utilization needs and usual system activity.\n\nCC7.1#10: Inspected the code repository configurations to determine that code repository was utilized to help detect unauthorized changes within the production environment.\n\nCC4.1#9: Inspected the security committee meeting minutes for a sample of months to determine that on a monthly basis, management reviewed the controls implemented within the environment for compliance and operational effectiveness and identified potential control gaps and weaknesses.\n\n**Result**\n\nCC7.1#3: No exceptions noted.\n\nCC4.1#12: No exceptions noted.\n\nCC6.6#10: No exceptions noted.\n\nCC7.1#2: No exceptions noted.\n\nCC7.1#10: No exceptions noted.\n\nCC4.1#9: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "VDR-TFR-MVX", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Liferay SaaS inherits Certification Data Generation controls from Paramify Cloud - 20x Moderate." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC4.1#9: Inspected the security committee meeting minutes for a sample of months to determine that on a monthly basis, management reviewed the controls implemented within the environment for compliance and operational effectiveness and identified potential control gaps and weaknesses.\n\nCC7.1#2: Inspected the monitoring tool configurations, the antivirus software dashboard console, the firewall rulesets for production environments and the IDS configurations to determine that monitoring software was used to identify and evaluate ongoing system performance, capacity, security threats, changing resource utilization needs and usual system activity.\n\nCC8.1#3: Inspected the code repository configurations to determine that code repository was utilized to help detect unauthorized changes within the production environment.\n\n**Result**\n\nCC4.1#9: No exceptions noted.\n\nCC7.1#2: No exceptions noted.\n\nCC8.1#3: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "VDR-TFR-PCD", "frrImplementationStatus": "Implemented", "frrImplementation": [ "During development and testing, the DevOps Admin and @Developer analyze builds for vulnerabilities using [Code Scanning: @Xbow]. Security flaws trigger a ticket in [System Development Management: @Jira] for the @Developer to fix. Only approved builds move to production. Remediation progress is monitored by the DevOps Admin.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for annual vulnerability scanning and penetration testing of the Liferay SaaS environment.\n\nMonthly vulnerability scanning is performed by #THIS ORGANIZATION for:\n\n- Servers: [Infrastructure Scanning: @Prisma Cloud]\n\n- Containers: [Container Scanning: @Prisma Cloud]\n\n- Databases: [Infrastructure Scanning: @Prisma Cloud]\n\n- Web: [Application Scanning: @Prisma Cloud]\n\nThe POA&M document is updated monthly with remediation activities for any high, moderate, or low-risk vulnerabilities identified in ongoing assessments and scans. Raw scan reports are made available to @Authorizing Official monthly.", "The InfoSec Admin manages the timely resolution of vulnerabilities, categorized by severity:\n\n- Critical-risk: within 2 days,\n\n- High-risk: within 30 days,\n\n- Moderate-risk: within 90 days,\n\n- Low-risk: within 180 days.\n\nVulnerabilities are logged, assigned to respective component owners, and tracked to resolution in [IT Service Management: @Jira Service Management]." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC7.1#3: Inspected the vulnerability scanning policies and procedures, the completed vulnerability scan results and the associated resolution documentation for a sample of identified vulnerabilities to determine that vulnerability scans were performed annually and remedial actions were taken where necessary.\n\nCC4.1#12: Inspected the completed penetration test results and the supporting incident ticket for a sample of vulnerabilities identified from vulnerability scans or penetration tests to determine that a third-party performed penetration testing annually to identify and exploit vulnerabilities identified within the environment, and identified vulnerabilities were addressed and tracked to resolution.\n\n**Result**\n\nCC7.1#3: No exceptions noted.\n\nCC4.1#12: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "VDR-TFR-PDD", "frrImplementationStatus": "Implemented", "frrImplementation": [ "During development and testing, the DevOps Admin and @Developer analyze builds for vulnerabilities using [Code Scanning: @Xbow]. Security flaws trigger a ticket in [System Development Management: @Jira] for the @Developer to fix. Only approved builds move to production. Remediation progress is monitored by the DevOps Admin.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for annual vulnerability scanning and penetration testing of the Liferay SaaS environment.\n\nMonthly vulnerability scanning is performed by #THIS ORGANIZATION for:\n\n- Servers: [Infrastructure Scanning: @Prisma Cloud]\n\n- Containers: [Container Scanning: @Prisma Cloud]\n\n- Databases: [Infrastructure Scanning: @Prisma Cloud]\n\n- Web: [Application Scanning: @Prisma Cloud]\n\nThe POA&M document is updated monthly with remediation activities for any high, moderate, or low-risk vulnerabilities identified in ongoing assessments and scans. Raw scan reports are made available to @Authorizing Official monthly.", "The InfoSec Admin manages the timely resolution of vulnerabilities, categorized by severity:\n\n- Critical-risk: within 2 days,\n\n- High-risk: within 30 days,\n\n- Moderate-risk: within 90 days,\n\n- Low-risk: within 180 days.\n\nVulnerabilities are logged, assigned to respective component owners, and tracked to resolution in [IT Service Management: @Jira Service Management]." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC7.1#3: Inspected the vulnerability scanning policies and procedures, the completed vulnerability scan results and the associated resolution documentation for a sample of identified vulnerabilities to determine that vulnerability scans were performed annually and remedial actions were taken where necessary.\n\nCC8.1#3: Inspected the code repository configurations to determine that code repository was utilized to help detect unauthorized changes within the production environment.\n\n**Result**\n\nCC7.1#3: No exceptions noted.\n\nCC8.1#3: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "VDR-TFR-PSD", "frrImplementationStatus": "Implemented", "frrImplementation": [ "During development and testing, the DevOps Admin and @Developer analyze builds for vulnerabilities using [Code Scanning: @Xbow]. Security flaws trigger a ticket in [System Development Management: @Jira] for the @Developer to fix. Only approved builds move to production. Remediation progress is monitored by the DevOps Admin.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for annual vulnerability scanning and penetration testing of the Liferay SaaS environment.\n\nMonthly vulnerability scanning is performed by #THIS ORGANIZATION for:\n\n- Servers: [Infrastructure Scanning: @Prisma Cloud]\n\n- Containers: [Container Scanning: @Prisma Cloud]\n\n- Databases: [Infrastructure Scanning: @Prisma Cloud]\n\n- Web: [Application Scanning: @Prisma Cloud]\n\nThe POA&M document is updated monthly with remediation activities for any high, moderate, or low-risk vulnerabilities identified in ongoing assessments and scans. Raw scan reports are made available to @Authorizing Official monthly.", "The InfoSec Admin manages the timely resolution of vulnerabilities, categorized by severity:\n\n- Critical-risk: within 2 days,\n\n- High-risk: within 30 days,\n\n- Moderate-risk: within 90 days,\n\n- Low-risk: within 180 days.\n\nVulnerabilities are logged, assigned to respective component owners, and tracked to resolution in [IT Service Management: @Jira Service Management]." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nInspected the vulnerability scanning policies and procedures, the completed vulnerability scan results and the associated resolution documentation for a sample of identified vulnerabilities to determine that vulnerability scans were performed annually and remedial actions were taken where necessary.\n\n**Result**\n\nNo exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "VDR-TFR-PVR", "frrImplementationStatus": "Implemented", "frrImplementation": [ "Identified issues resulting from [Continuous Monitoring Process: @Continuous Monitoring Process] are given owners and tracked to remediation via [GRC Tool: @Paramify SaaS].", "Automated patching of Liferay SaaS infrastructure is configured by the DevOps Admin using [Inventory Management: @Cloud Asset Inventory]. Approved patches are deployed during the next scheduled maintenance window.", "[Compliance Deliverables Management: @Paramify SaaS] acts as the central automation engine and system of record for compliance activities. They provide the technical infrastructure, workflow templates, and data integration capabilities to facilitate Automated Detection and risk-based analysis based on Internet-Reachability, Likely Exploitability, and Potential Adverse Impact. It serves as the primary interface for the documentation and oversight of controls.\n\nThe platform specifically enables:\n\n- Machine-Readable History: Automates the availability of recent historical vulnerability detection and response activity in a machine-readable format for retrieval, updated at least every 14 days.\n\n- Detection Infrastructure: Provides the dedicated modules and scheduling capabilities required to track recurring machine-based and resource-specific detection cycles.\n\n- Standardized Scoring: Automates the correlation of technical telemetry against mission-critical evaluation factors to ensure consistent prioritization based on actual risk.\n\nThe InfoSec Admin is responsible for the active configuration and management of [Compliance Deliverables Management: @Paramify SaaS] to ensure all FedRAMP 20x Class A compliance timelines and control requirements are met. The InfoSec Admin manages the operational triage of vulnerabilities by importing data from security tools, performing manual validation to identify False Positives, and consolidating identical machine resources into Logical Groupings.\n\nNOTE: Pick the VDR Operational Requirements and the 20x timeframes table that are relevant to your FedRAMP impact level.\n\n20x Low - VDR operational requirements\n\nTo satisfy Low-baseline requirements, the Implementer must tune the platform to execute and document the following:\n\n- Detection cadences: Perform Weekly Sampling for similar machine-based resources, Monthly Drift Detection for high-drift resources, and Six-Month Detection for stable resources.\n\n- Rapid evaluation: Evaluate all detected vulnerabilities as required by VDR-07, VDR-08, and VDR-09 within 7 days of detection.\n\n- Incident management: No baseline-specific incident treatment requirement at Low. Standard incident communications procedures (ICP) still apply.\n\n- Mitigation timeframes: Ensure vulnerabilities are partially mitigated, fully mitigated, or remediated within the specific Low maximum timeframes (e.g., 4 days for LEV+IRV N5) based on their risk profile.\n\n20x Moderate - VDR operational requirements\n\nTo satisfy Moderate-baseline requirements, the Implementer must tune the platform to execute and document the following:\n\n- Detection Cadences: Perform 3-Day Sampling for similar machine-based resources, 14-Day Drift Detection for high-drift resources, and Monthly Detection for stable resources.\n\n- Rapid Evaluation: Evaluate all detected vulnerabilities as required by VDR-07, VDR-08, and VDR-09 within 5 days of detection.\n\n- Incident Management: Treat internet-reachable, likely exploitable vulnerabilities with a potential adverse impact of N4 or N5 as security incidents until partially mitigated to N3 or below.\n\n- Mitigation Timeframes: Ensure vulnerabilities are partially mitigated, fully mitigated, or remediated within the specific Moderate maximum timeframes (e.g., 24 hours for LEV+IRV N5) based on their risk profile.\n\n| Potential Adverse Impact | LEV + IRV | LEV + NIRV | NLEV |\n| --- | --- | --- | --- |\n| N5 | 4 | 8 | 32 |\n| N4 | 8 | 32 | 64 |\n| N3 | 32 | 64 | 192 |\n| N2 | 96 | 160 | 192 |\n\n| Potential Adverse Impact | LEV + IRV | LEV + NIRV | NLEV |\n| --- | --- | --- | --- |\n| N5 | 2 | 4 | 16 |\n| N4 | 4 | 8 | 64 |\n| N3 | 16 | 32 | 128 |\n| N2 | 48 | 128 | 192 |", "The InfoSec Admin manages the timely resolution of vulnerabilities, categorized by severity:\n\n- Critical-risk: within 2 days,\n\n- High-risk: within 30 days,\n\n- Moderate-risk: within 90 days,\n\n- Low-risk: within 180 days.\n\nVulnerabilities are logged, assigned to respective component owners, and tracked to resolution in [IT Service Management: @Jira Service Management].", "The @GRC Admin is responsible for managing all interactions with external oversight bodies, ensuring that the organization does not reject requests for information from Law Enforcement, Congress, Inspectors General, or the FedRAMP PMO. The @GRC Admin ensures that human-readable reports are distributed to all necessary parties at least monthly, summarizing all detection and response activity since the previous report. When triggered by a CAP or a specific investigation, [GRC Tool: @Paramify SaaS] is used to generate alternative reports or provide the sensitive details necessary for an informed risk-based decision by government investigators." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC4.1#12: Inspected the completed penetration test results and the supporting incident ticket for a sample of vulnerabilities identified from vulnerability scans or penetration tests to determine that a third-party performed penetration testing annually to identify and exploit vulnerabilities identified within the environment, and identified vulnerabilities were addressed and tracked to resolution.\n\nCC4.2#10: Inspected the security committee meeting minutes for a sample of months to determine that management tracked whether vulnerabilities, deviations and control failures/gaps identified as part of the evaluations performed were addressed in a timely manner.\n\nCC4.2#8: Inspected the completed risk assessment, the completed vulnerability scan results, the completed penetration test results and the supporting incident ticket for a sample of vulnerabilities, deviations and internal control failures/gaps to determine that vulnerabilities, deviations and control failures/gaps identified from the various assessments performed on the environment were documented, investigated and addressed.\n\nCC7.4#14: Inspected the supporting remediation ticket for a sample of vulnerabilities to determine that the risks associated with the identified vulnerabilities were addressed using one of the following strategies: • Avoid the risk • Mitigate the risk • Transfer the risk • Accept the risk\n\nCC8.1#9: Inspected the vulnerability and patch management policy and the supporting change ticket for a sample of system patches to determine that system patches/security updates follow the standard patch management process.\n\n**Result**\n\nCC4.1#12: No exceptions noted.\n\nCC4.2#10: No exceptions noted.\n\nCC4.2#8: No exceptions noted.\n\nCC7.4#14: No exceptions noted.\n\nCC8.1#9: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "VER-EVA-EPA", "frrImplementationStatus": "Implemented", "frrImplementation": [ "The InfoSec Admin establishes a channel for receiving public vulnerability reports for relevant components within Liferay SaaS.", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for annual vulnerability scanning and penetration testing of the Liferay SaaS environment.\n\nMonthly vulnerability scanning is performed by #THIS ORGANIZATION for:\n\n- Servers: [Infrastructure Scanning: @Prisma Cloud]\n\n- Containers: [Container Scanning: @Prisma Cloud]\n\n- Databases: [Infrastructure Scanning: @Prisma Cloud]\n\n- Web: [Application Scanning: @Prisma Cloud]\n\nThe POA&M document is updated monthly with remediation activities for any high, moderate, or low-risk vulnerabilities identified in ongoing assessments and scans. Raw scan reports are made available to @Authorizing Official monthly.", "The InfoSec Admin manages the timely resolution of vulnerabilities, categorized by severity:\n\n- Critical-risk: within 2 days,\n\n- High-risk: within 30 days,\n\n- Moderate-risk: within 90 days,\n\n- Low-risk: within 180 days.\n\nVulnerabilities are logged, assigned to respective component owners, and tracked to resolution in [IT Service Management: @Jira Service Management]." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "VER-TFR-EVU", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION conducts [Penetration Testing Process: @Penetration Testing Process] on Liferay SaaS to detect any non-public information that is publicly accessible. If any such information is found, it is investigated and remediated following the [Incident Response Process: @Incident Response Process].", "The InfoSec Admin establishes a channel for receiving public vulnerability reports for relevant components within Liferay SaaS.", "[Compliance Deliverables Management: @Paramify SaaS] acts as the central automation engine and system of record for compliance activities. They provide the technical infrastructure, workflow templates, and data integration capabilities to facilitate Automated Detection and risk-based analysis based on Internet-Reachability, Likely Exploitability, and Potential Adverse Impact. It serves as the primary interface for the documentation and oversight of controls.\n\nThe platform specifically enables:\n\n- Machine-Readable History: Automates the availability of recent historical vulnerability detection and response activity in a machine-readable format for retrieval, updated at least every 14 days.\n\n- Detection Infrastructure: Provides the dedicated modules and scheduling capabilities required to track recurring machine-based and resource-specific detection cycles.\n\n- Standardized Scoring: Automates the correlation of technical telemetry against mission-critical evaluation factors to ensure consistent prioritization based on actual risk.\n\nThe InfoSec Admin is responsible for the active configuration and management of [Compliance Deliverables Management: @Paramify SaaS] to ensure all FedRAMP 20x Class A compliance timelines and control requirements are met. The InfoSec Admin manages the operational triage of vulnerabilities by importing data from security tools, performing manual validation to identify False Positives, and consolidating identical machine resources into Logical Groupings.\n\nNOTE: Pick the VDR Operational Requirements and the 20x timeframes table that are relevant to your FedRAMP impact level.\n\n20x Low - VDR operational requirements\n\nTo satisfy Low-baseline requirements, the Implementer must tune the platform to execute and document the following:\n\n- Detection cadences: Perform Weekly Sampling for similar machine-based resources, Monthly Drift Detection for high-drift resources, and Six-Month Detection for stable resources.\n\n- Rapid evaluation: Evaluate all detected vulnerabilities as required by VDR-07, VDR-08, and VDR-09 within 7 days of detection.\n\n- Incident management: No baseline-specific incident treatment requirement at Low. Standard incident communications procedures (ICP) still apply.\n\n- Mitigation timeframes: Ensure vulnerabilities are partially mitigated, fully mitigated, or remediated within the specific Low maximum timeframes (e.g., 4 days for LEV+IRV N5) based on their risk profile.\n\n20x Moderate - VDR operational requirements\n\nTo satisfy Moderate-baseline requirements, the Implementer must tune the platform to execute and document the following:\n\n- Detection Cadences: Perform 3-Day Sampling for similar machine-based resources, 14-Day Drift Detection for high-drift resources, and Monthly Detection for stable resources.\n\n- Rapid Evaluation: Evaluate all detected vulnerabilities as required by VDR-07, VDR-08, and VDR-09 within 5 days of detection.\n\n- Incident Management: Treat internet-reachable, likely exploitable vulnerabilities with a potential adverse impact of N4 or N5 as security incidents until partially mitigated to N3 or below.\n\n- Mitigation Timeframes: Ensure vulnerabilities are partially mitigated, fully mitigated, or remediated within the specific Moderate maximum timeframes (e.g., 24 hours for LEV+IRV N5) based on their risk profile.\n\n| Potential Adverse Impact | LEV + IRV | LEV + NIRV | NLEV |\n| --- | --- | --- | --- |\n| N5 | 4 | 8 | 32 |\n| N4 | 8 | 32 | 64 |\n| N3 | 32 | 64 | 192 |\n| N2 | 96 | 160 | 192 |\n\n| Potential Adverse Impact | LEV + IRV | LEV + NIRV | NLEV |\n| --- | --- | --- | --- |\n| N5 | 2 | 4 | 16 |\n| N4 | 4 | 8 | 64 |\n| N3 | 16 | 32 | 128 |\n| N2 | 48 | 128 | 192 |", "#THIS ORGANIZATION contracts with a CR26 FedRAMP 20x-accredited @Red Team for annual vulnerability scanning and penetration testing of the Liferay SaaS environment.\n\nMonthly vulnerability scanning is performed by #THIS ORGANIZATION for:\n\n- Servers: [Infrastructure Scanning: @Prisma Cloud]\n\n- Containers: [Container Scanning: @Prisma Cloud]\n\n- Databases: [Infrastructure Scanning: @Prisma Cloud]\n\n- Web: [Application Scanning: @Prisma Cloud]\n\nThe POA&M document is updated monthly with remediation activities for any high, moderate, or low-risk vulnerabilities identified in ongoing assessments and scans. Raw scan reports are made available to @Authorizing Official monthly.", "The InfoSec Admin manages the timely resolution of vulnerabilities, categorized by severity:\n\n- Critical-risk: within 2 days,\n\n- High-risk: within 30 days,\n\n- Moderate-risk: within 90 days,\n\n- Low-risk: within 180 days.\n\nVulnerabilities are logged, assigned to respective component owners, and tracked to resolution in [IT Service Management: @Jira Service Management]." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC4.2#8: Inspected the completed risk assessment, the completed vulnerability scan results, the completed penetration test results and the supporting incident ticket for a sample of vulnerabilities, deviations and internal control failures/gaps to determine that vulnerabilities, deviations and control failures/gaps identified from the various assessments performed on the environment were documented, investigated and addressed.\n\nCC4.2#7: Inspected the completed risk assessment, the completed vulnerability scan results, the completed penetration test results and the supporting incident ticket for a sample of vulnerabilities, deviations and internal control failures/gaps to determine that vulnerabilities, deviations and control failures/gaps identified from the various assessments performed on the environment were communicated to those parties responsible for taking corrective actions.\n\nCC9.1#3: Inspected the risk assessment and management policies and procedures and completed risk assessment to determine that identified risks were rated using a risk evaluation process and ratings were approved by management.\n\n**Result**\n\nCC4.2#8: No exceptions noted.\n\nCC4.2#7: No exceptions noted.\n\nCC9.1#3: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ] }, { "frrID": "VER-TFR-IRI", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION evaluates, rates, and reports incidents in accordance with FedRAMP Incident Evaluation and Communications rules. The @Incident Response Admin promptly evaluates each incident to determine whether it affects, or is likely to affect, the confidentiality or integrity of federal customer data; such incidents are treated as FedRAMP Reportable Incidents. For each FedRAMP Reportable Incident, #THIS ORGANIZATION promptly estimates the likely adverse impact on agency customers to assign a Potential Agency Impact N-rating (PAIN); until that rating is estimated, the incident is treated as if it has a PAIN rating of 5.\n\n#THIS ORGANIZATION responsibly notifies all affected parties across the incident lifecycle: an Initial Incident Report after identifying a FedRAMP Reportable Incident, Ongoing Incident Reports as new information becomes available during response, and a Final Incident Report once the incident is resolved and recovery is complete. Automation is used where practical to minimize human intervention in reporting to affected parties. Reports are generated in the FedRAMP-defined formats and validated against the corresponding FedRAMP JSON schema where one is provided.", "#THIS ORGANIZATION personnel report suspected or actual security incidents to the Incident Response Admin. #THIS ORGANIZATION also detects potential incidents from sources, including:\n\n- [Security Information and Event Management (SIEM): @Google Security Operations SIEM]\n\n- [Infrastructure Scanning: @Prisma Cloud] Vulnerability Scans\n\n- US-CERT\n\n- Vendor bulletins and reports\n\n@Security Operations Center Admin flags events for the Incident Response Admin to review. The Incident Response Admin creates an incident in [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] after confirming the event is a security incident. The Incident Response Admin analyzes and remediates the incident, documenting each step in the [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] until it is resolved.", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan", "[Compliance Deliverables Management: @Paramify SaaS] acts as the central automation engine and system of record for compliance activities. They provide the technical infrastructure, workflow templates, and data integration capabilities to facilitate Automated Detection and risk-based analysis based on Internet-Reachability, Likely Exploitability, and Potential Adverse Impact. It serves as the primary interface for the documentation and oversight of controls.\n\nThe platform specifically enables:\n\n- Machine-Readable History: Automates the availability of recent historical vulnerability detection and response activity in a machine-readable format for retrieval, updated at least every 14 days.\n\n- Detection Infrastructure: Provides the dedicated modules and scheduling capabilities required to track recurring machine-based and resource-specific detection cycles.\n\n- Standardized Scoring: Automates the correlation of technical telemetry against mission-critical evaluation factors to ensure consistent prioritization based on actual risk.\n\nThe InfoSec Admin is responsible for the active configuration and management of [Compliance Deliverables Management: @Paramify SaaS] to ensure all FedRAMP 20x Class A compliance timelines and control requirements are met. The InfoSec Admin manages the operational triage of vulnerabilities by importing data from security tools, performing manual validation to identify False Positives, and consolidating identical machine resources into Logical Groupings.\n\nNOTE: Pick the VDR Operational Requirements and the 20x timeframes table that are relevant to your FedRAMP impact level.\n\n20x Low - VDR operational requirements\n\nTo satisfy Low-baseline requirements, the Implementer must tune the platform to execute and document the following:\n\n- Detection cadences: Perform Weekly Sampling for similar machine-based resources, Monthly Drift Detection for high-drift resources, and Six-Month Detection for stable resources.\n\n- Rapid evaluation: Evaluate all detected vulnerabilities as required by VDR-07, VDR-08, and VDR-09 within 7 days of detection.\n\n- Incident management: No baseline-specific incident treatment requirement at Low. Standard incident communications procedures (ICP) still apply.\n\n- Mitigation timeframes: Ensure vulnerabilities are partially mitigated, fully mitigated, or remediated within the specific Low maximum timeframes (e.g., 4 days for LEV+IRV N5) based on their risk profile.\n\n20x Moderate - VDR operational requirements\n\nTo satisfy Moderate-baseline requirements, the Implementer must tune the platform to execute and document the following:\n\n- Detection Cadences: Perform 3-Day Sampling for similar machine-based resources, 14-Day Drift Detection for high-drift resources, and Monthly Detection for stable resources.\n\n- Rapid Evaluation: Evaluate all detected vulnerabilities as required by VDR-07, VDR-08, and VDR-09 within 5 days of detection.\n\n- Incident Management: Treat internet-reachable, likely exploitable vulnerabilities with a potential adverse impact of N4 or N5 as security incidents until partially mitigated to N3 or below.\n\n- Mitigation Timeframes: Ensure vulnerabilities are partially mitigated, fully mitigated, or remediated within the specific Moderate maximum timeframes (e.g., 24 hours for LEV+IRV N5) based on their risk profile.\n\n| Potential Adverse Impact | LEV + IRV | LEV + NIRV | NLEV |\n| --- | --- | --- | --- |\n| N5 | 4 | 8 | 32 |\n| N4 | 8 | 32 | 64 |\n| N3 | 32 | 64 | 192 |\n| N2 | 96 | 160 | 192 |\n\n| Potential Adverse Impact | LEV + IRV | LEV + NIRV | NLEV |\n| --- | --- | --- | --- |\n| N5 | 2 | 4 | 16 |\n| N4 | 4 | 8 | 64 |\n| N3 | 16 | 32 | 128 |\n| N2 | 48 | 128 | 192 |" ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "VER-TFR-MRH", "frrImplementationStatus": "Implemented", "frrImplementation": [ "At agreed-upon intervals, #THIS ORGANIZATION provides evidence of continuous monitoring and control assessments to the @Authorizing Official. The following content is provided monthly:\n\n- Vulnerability scanning: #THIS ORGANIZATION system scan reports and scan results are managed and mitigated in POA&Ms.\n\n- POA&M updates\n\nThe following security authorization documentation is provided annually:\n\nPolicies and procedures\n\n- [System Security Plan: @System Security Plan]\n\n- [Contingency Plan: @Contingency Plan],\n\n- [Configuration Management Plan: @Configuration Management Plan],\n\n- [Incident Response Plan: @Incident Response Plan]\n\n- Information Security Awareness and Personnel Training Records\n\n- Annual CR26 FedRAMP 20x Assessment: Delivered by a CR26 FedRAMP 20x-accredited 3PAO.\n\n- Incident Response Plan Test Report\n\n- Contingency Plan Test Report", "The @InfoSec Admin ensures the historical vulnerability detection and response activity made available for automated retrieval is updated persistently, at least once every 14 days.\n\nNote: Replace following text and brackets with appropriate validator mention and context.\n\nProgramatic Access to VDR data \\[Vulnerability Detection and Response : VDP Effectiveness Review\\] has an attestation that ensures that the Vulnerability Disclosure Program is actively monitored for effectiveness by reviewing public documentation, verifying the triage of incoming reports in the issue tracker, and auditing public repositories for secure communication.", "#THIS ORGANIZATION shares [Vulnerability Scanning Process: @Vulnerability Scanning Process] results and the Security Assessment Results (SAR) with the Customer ISSM, Customer ISSO, OMB MAX, and @Authorizing Official through DoD EMASS." ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] }, { "frrID": "VER-TFR-NRI", "frrImplementationStatus": "Implemented", "frrImplementation": [ "#THIS ORGANIZATION evaluates, rates, and reports incidents in accordance with FedRAMP Incident Evaluation and Communications rules. The @Incident Response Admin promptly evaluates each incident to determine whether it affects, or is likely to affect, the confidentiality or integrity of federal customer data; such incidents are treated as FedRAMP Reportable Incidents. For each FedRAMP Reportable Incident, #THIS ORGANIZATION promptly estimates the likely adverse impact on agency customers to assign a Potential Agency Impact N-rating (PAIN); until that rating is estimated, the incident is treated as if it has a PAIN rating of 5.\n\n#THIS ORGANIZATION responsibly notifies all affected parties across the incident lifecycle: an Initial Incident Report after identifying a FedRAMP Reportable Incident, Ongoing Incident Reports as new information becomes available during response, and a Final Incident Report once the incident is resolved and recovery is complete. Automation is used where practical to minimize human intervention in reporting to affected parties. Reports are generated in the FedRAMP-defined formats and validated against the corresponding FedRAMP JSON schema where one is provided.", "#THIS ORGANIZATION personnel report suspected or actual security incidents to the Incident Response Admin. #THIS ORGANIZATION also detects potential incidents from sources, including:\n\n- [Security Information and Event Management (SIEM): @Google Security Operations SIEM]\n\n- [Infrastructure Scanning: @Prisma Cloud] Vulnerability Scans\n\n- US-CERT\n\n- Vendor bulletins and reports\n\n@Security Operations Center Admin flags events for the Incident Response Admin to review. The Incident Response Admin creates an incident in [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] after confirming the event is a security incident. The Incident Response Admin analyzes and remediates the incident, documenting each step in the [Digital Forensics and Incident Response (DFIR): @Google Security Operations SIEM] until it is resolved.", "All personnel from #THIS ORGANIZATION must report any suspected or actual security incidents, including insider threats, to the Incident Response Admin via email, as indicated in the [Incident Response Plan: @Incident Response Plan]. Incidents should be reported within 1 hour of discovery, and the timeframes for different incident categories (see table) should be followed, unless the data owner specifies a more restrictive guidance.\n\nIncident Category Description Impact Notification Time Requirement\n\n1 Root Level Intrusion Moderate 2 Hours\n\n2 User Level Intrusion Moderate 2 Hours\n\n3 Unsuccessful Activity Attempt N/A 4 Hours\n\n4 Denial of Service Mod/High 15 Minutes\n\n5 Non-Compliance Activity N/A 4 Hours\n\n6 Reconnaissance N/A 4 Hours\n\n7 Malicious Logic Moderate 2 Hours\n\nAfter formally documenting and discovering an incident, the responding party communicates updates and remediation actions to all appropriate stakeholders. The type of incident determines which stakeholders are notified, including the affected organizations, the @InfoSec Admin, @Operations Admin, and support organizations.\n\nStakeholders receive an email from the Incident Response Admin, including the following information:\n\n- Issue name/identifier\n\n- Summary, impact\n\n- Current status\n\n- Stakeholders\n\n- Affected parties\n\n- Facts to date\n\n- Actions\n\n- How to learn more\n\n- Engagement/Update plan", "[Compliance Deliverables Management: @Paramify SaaS] acts as the central automation engine and system of record for compliance activities. They provide the technical infrastructure, workflow templates, and data integration capabilities to facilitate Automated Detection and risk-based analysis based on Internet-Reachability, Likely Exploitability, and Potential Adverse Impact. It serves as the primary interface for the documentation and oversight of controls.\n\nThe platform specifically enables:\n\n- Machine-Readable History: Automates the availability of recent historical vulnerability detection and response activity in a machine-readable format for retrieval, updated at least every 14 days.\n\n- Detection Infrastructure: Provides the dedicated modules and scheduling capabilities required to track recurring machine-based and resource-specific detection cycles.\n\n- Standardized Scoring: Automates the correlation of technical telemetry against mission-critical evaluation factors to ensure consistent prioritization based on actual risk.\n\nThe InfoSec Admin is responsible for the active configuration and management of [Compliance Deliverables Management: @Paramify SaaS] to ensure all FedRAMP 20x Class A compliance timelines and control requirements are met. The InfoSec Admin manages the operational triage of vulnerabilities by importing data from security tools, performing manual validation to identify False Positives, and consolidating identical machine resources into Logical Groupings.\n\nNOTE: Pick the VDR Operational Requirements and the 20x timeframes table that are relevant to your FedRAMP impact level.\n\n20x Low - VDR operational requirements\n\nTo satisfy Low-baseline requirements, the Implementer must tune the platform to execute and document the following:\n\n- Detection cadences: Perform Weekly Sampling for similar machine-based resources, Monthly Drift Detection for high-drift resources, and Six-Month Detection for stable resources.\n\n- Rapid evaluation: Evaluate all detected vulnerabilities as required by VDR-07, VDR-08, and VDR-09 within 7 days of detection.\n\n- Incident management: No baseline-specific incident treatment requirement at Low. Standard incident communications procedures (ICP) still apply.\n\n- Mitigation timeframes: Ensure vulnerabilities are partially mitigated, fully mitigated, or remediated within the specific Low maximum timeframes (e.g., 4 days for LEV+IRV N5) based on their risk profile.\n\n20x Moderate - VDR operational requirements\n\nTo satisfy Moderate-baseline requirements, the Implementer must tune the platform to execute and document the following:\n\n- Detection Cadences: Perform 3-Day Sampling for similar machine-based resources, 14-Day Drift Detection for high-drift resources, and Monthly Detection for stable resources.\n\n- Rapid Evaluation: Evaluate all detected vulnerabilities as required by VDR-07, VDR-08, and VDR-09 within 5 days of detection.\n\n- Incident Management: Treat internet-reachable, likely exploitable vulnerabilities with a potential adverse impact of N4 or N5 as security incidents until partially mitigated to N3 or below.\n\n- Mitigation Timeframes: Ensure vulnerabilities are partially mitigated, fully mitigated, or remediated within the specific Moderate maximum timeframes (e.g., 24 hours for LEV+IRV N5) based on their risk profile.\n\n| Potential Adverse Impact | LEV + IRV | LEV + NIRV | NLEV |\n| --- | --- | --- | --- |\n| N5 | 4 | 8 | 32 |\n| N4 | 8 | 32 | 64 |\n| N3 | 32 | 64 | 192 |\n| N2 | 96 | 160 | 192 |\n\n| Potential Adverse Impact | LEV + IRV | LEV + NIRV | NLEV |\n| --- | --- | --- | --- |\n| N5 | 2 | 4 | 16 |\n| N4 | 4 | 8 | 64 |\n| N3 | 16 | 32 | 128 |\n| N2 | 48 | 128 | 192 |" ], "frrRemarks": "", "frrValidation": [], "frrAssessment": [] } ], "keySecurityIndicators": [ { "ksiId": "KSI-CED-RAT", "ksiImplementationStatus": "Implemented", "ksiImplementation": [ "#THIS ORGANIZATION mandates security training with [Security Learning Management System: @Optiv] before access to Liferay SaaS. The training covers basic security principles, social engineering risks, supply chain risks, credential protection and remote access risk. This training is updated and documented annually, or when events dictate a revision of content. Employees' training records are kept in [HR Platform: @UKG HCM] for at least five years.", "#THIS ORGANIZATION employees receive annual training or training when there is a change to the Liferay SaaS . The @Change Control Board sends email notifications to the Security Training and Awareness Admin training module staff for training updates. Managers email employees when training is due and follow up on delinquent reports. All training is recorded and retained for five years in [Security Learning Management System: @Optiv]." ], "ksiRemarks": "", "ksiValidation": [], "ksiAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC2.2#10: Inspected the information security awareness training completion form for a sample of current employees to determine that current employees were required to complete information security awareness training annually.\n\nCC2.2#9: Inquired of the Cloud Operations Administrator regarding security awareness training to determine that upon hire, personnel were required to complete information security awareness training.\n\nInspected the employee hiring, transfer and termination policy to determine that upon hire, personnel were required to complete information security awareness training.\n\nInspected the information security awareness training completion form for a sample of new hires to determine that upon hire, personnel were required to complete information security awareness training.\n\nCC1.4#8: Inspected the Continued Professional Education (CPE) training tracker to determine that employees were required to attend continued training annually that relates to their job role and responsibilities.\n\nCC1.4#11: Inspected the CPE training tracker to determine that executive management tracked and monitored compliance with CPE training requirements.\n\nCC1.4#9: Inspected the information security awareness training program to determine that executive management created a training program for its employees.\n\nA1.3#3: Inspected the completed business continuity and disaster recovery test results for a sample of quarters to determine that the business continuity and disaster recovery plans were tested on a quarterly basis.\n\nCC7.3#3: Inspected the revision history of the incident response policies and procedures to determine that the incident response and escalation procedures were reviewed at least annually for effectiveness.\n\n**Result**\n\nCC2.2#10: No exceptions noted.\n\nCC2.2#9: No exceptions noted.\n\nNo exceptions noted.\n\nTesting of the control activity disclosed that there were no new hires during the review period.\n\nCC1.4#8: No exceptions noted.\n\nCC1.4#11: No exceptions noted.\n\nCC1.4#9: No exceptions noted.\n\nA1.3#3: No exceptions noted.\n\nCC7.3#3: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ], "ksiTests": [], "ksiEvidence": [] }, { "ksiId": "KSI-CMT-LMC", "ksiImplementationStatus": "Implemented", "ksiImplementation": [ "The Change Control Board is notified of deployed changes via [Event Notifications: @OpsGenie].", "Change proposals for Liferay SaaS are assessed in [System Development Management: @Jira] by component owners, encompassing activities and decisions. The @Change Control Board conducts bi-weekly monitoring of the [Change Management Process: @Change Management Process]. Only administrators with [Privileged Access Management: @GCP IAM] authorization can execute changes.\n\nThe @DevOps Admin tracks and records all releases for Liferay SaaS indefinitely using [CI/CD Runners: @Jenkins]." ], "ksiRemarks": "", "ksiValidation": [], "ksiAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC8.1#11: Inspected the supporting change ticket for a sample of infrastructure, system and application changes to determine that system change requests were documented and tracked in a ticketing system.\n\nCC8.1#3: Inspected the code repository configurations to determine that code repository was utilized to help detect unauthorized changes within the production environment.\n\nCC8.1#4: Inspected the code repository notification configurations and an example alert generated from the code repository to determine that the code repository was configured to notify IT personnel via email alert when a change to the production application code files was detected.\n\nCC8.1#7: Inspected the supporting change ticket for a sample of infrastructure, system and application changes to determine that system changes were authorized and approved by management prior to implementation.\n\nCC8.1#13: Inspected the supporting change ticket for a sample of infrastructure, system and application changes to determine that a code review was systematically required prior to deploying the PR into the production environment.\n\nCC8.1#9: Inspected the vulnerability and patch management policy and the supporting change ticket for a sample of system patches to determine that system patches/security updates follow the standard patch management process.\n\nCC7.2#5: Inspected the production server account lockout configurations to determine that production server account lockout configurations were in place that included: • Account lockout duration • Account lockout threshold • Account lockout counter reset\n\nInspected the production server audit logging configurations and an example production server audit log extract to determine that production server audit logging configurations were in place that included: • Account logon events • Account management • Directory Service Access • Logon events • Object access • Policy changes • Privilege use • Process tracking • System events\n\nInquired of the Senior Manager, Information Security regarding production server audit logs to determine that production server audit logs were maintained for review when needed.\n\nInspected an example production server audit log extract to determine that production server audit logs were maintained for review when needed.\n\n**Result**\n\nCC8.1#11: No exceptions noted.\n\nCC8.1#3: No exceptions noted.\n\nCC8.1#4: No exceptions noted.\n\nCC8.1#7: No exceptions noted.\n\nCC8.1#13: No exceptions noted.\n\nCC8.1#9: No exceptions noted.\n\nCC7.2#5: No exceptions noted.\n\nNo exceptions noted.\n\nNo exceptions noted.\n\nNo exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ], "ksiTests": [], "ksiEvidence": [] }, { "ksiId": "KSI-CNA-RNT", "ksiImplementationStatus": "Implemented", "ksiImplementation": [ "#THIS ORGANIZATION authorizes and documents all internal Liferay SaaS connections in line with the [Change Management Process: @Change Management Process]. The process, led by the @Change Control Board and documented in [Project Management: @Jira], includes risk, security, and regression testing. This applies to components like admin laptops and productivity tools, which are tested, assessed, and hardened to standards. Internal connections extending outside the system boundary are also documented, outlining their security requirements and interface details.", "Any exceptions to the traffic flow policy require approval via [Change Management Process: @Change Management Process] with a review to evaluate the need and business justification. Once the exception is no longer needed, the associated interface is reconfigured to default policy and the ticket closed. Exceptions are reviewed by the Change Control Board at least annually.", "External systems accessing Liferay SaaS must meet #THIS ORGANIZATION data protection requirements, verified through [Vendor Risk Management Process: @Vendor Risk Management Process]. The Vendor Risk Management Admin reviews interconnections on a monthly basis to ensure all interconnections are approved." ], "ksiRemarks": "", "ksiValidation": [], "ksiAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC6.6#9: Inspected the network diagram and the firewall rulesets for the production environment to determine that the firewall system was configured to deny any type of network connection that was not explicitly authorized by a firewall system rule.\n\nCC6.6#8: Inspected the network diagram and the firewall rulesets for the production environment to determine that a firewall was in place to filter unauthorized inbound network traffic from the Internet.\n\nCC6.1#27: Inquired of the Information Security Program Manager regarding network segmentation to determine that the entity’s various networks were segmented to keep information and data isolated and restricted to authorized personnel.\n\nInspected the multiple Virtual Private Clouds (VPCs) in the cloud environment to determine that the entity’s various networks were segmented to keep information and data isolated and restricted to authorized personnel.\n\nCC6.1#29: Inspected the DMZ settings and the firewall rulesets for the production environment to determine that a DMZ and firewall rulesets were in place to isolate outside access and data from the entity’s environment.\n\nCC6.1#28: Inspected the IDS configurations, the firewall rulesets for the production environment and the network diagram to determine that data coming into the environment was secured and monitored through the use of firewalls and an IDS.\n\nCC6.6#10: Inspected the network diagram and IDS configurations to determine that an IDS was utilized to analyze network events and report possible or actual network security breaches.\n\n**Result**\n\nCC6.6#9: No exceptions noted.\n\nCC6.6#8: No exceptions noted.\n\nCC6.1#27: No exceptions noted.\n\nNo exceptions noted.\n\nCC6.1#29: No exceptions noted.\n\nCC6.1#28: No exceptions noted.\n\nCC6.6#10: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ], "ksiTests": [], "ksiEvidence": [] }, { "ksiId": "KSI-IAM-AAM", "ksiImplementationStatus": "Implemented", "ksiImplementation": [ "The Customer Admin is responsible for managing account access to their own Liferay SaaS environment and network.", "Identity Team conduct the [Logical Access Certification Process: @Logical Access Certification Process] for Liferay SaaS monthly, using access groups within [Identity Management: @Okta Directory]. Users are validated to determine whether they need continued access. If no response is given, the user is automatically removed from the corresponding [Identity Management: @Okta Directory] group." ], "ksiRemarks": "", "ksiValidation": [], "ksiAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC6.2#4: Inquired of the Senior Manager, Information Security regarding the hiring process to determine that logical access to systems was approved and granted to personnel as a component of the hiring process.\n\nInspected the employee hiring, transfer and termination policy to determine that logical access to systems was approved and granted to personnel as a component of the hiring process.\n\nInspected the in-scope user listings and the user access request ticket for a sample of new hires to determine that logical access to systems was approved and granted to personnel as a component of the hiring process.\n\nCC6.2#5: Inquired of the Senior Manager, Information Security regarding the termination process to determine that logical access to systems was revoked as a component of the termination process.\n\nInspected the termination procedures, in-scope user listings, and user access revocation ticket and logs for a sample of terminated employees to determine that logical access to systems was revoked from personnel as a component of the termination process.\n\nCC6.2#3: Inquired of the Senior Manager, Information Security regarding user access reviews to determine that logical access reviews were performed quarterly.\n\nInspected the completed access review for the in-scope systems for a sample of quarters to determine that logical access reviews were performed quarterly.\n\nCC6.1#3: Inquired of the Senior Manager, Information Security regarding the authentication of a user to GCP to determine that network users were authenticated via SSO.\n\nObserved the authentication of a user to GCP to determine that GCP users were authenticated via SSO.\n\nInspected the GCP user listing and password configurations to determine that GCP users were authenticated via SSO.\n\nCC6.1#9: Inquired of the Senior Manager, Information Security regarding network access to determine that network user access was restricted via role-based security privileges defined within the access control system.\n\nInspected the Okta user listing and access rights to determine that Okta user access was restricted via role-based security privileges defined within the access control system.\n\nCC6.2#6: Inquired of the Senior Manager, Information Security regarding privileged access to sensitive resources to determine that privileged access to sensitive resources add, remove, or modify access to user accounts was restricted to authorized personnel.\n\nInspected the listing of privileged users to the in-scope systems to determine that privileged access to add, remove, or modify access to user accounts was restricted to authorized personnel.\n\n**Result**\n\nCC6.2#4: No exceptions noted.\n\nNo exceptions noted.\n\nTesting of the control activity disclosed that there were no new hires during the review period.\n\nCC6.2#5: No exceptions noted.\n\nNo exceptions noted.\n\nCC6.2#3: No exceptions noted.\n\nNo exceptions noted.\n\nCC6.1#3: No exceptions noted.\n\nNo exceptions noted.\n\nNo exceptions noted.\n\nCC6.1#9: No exceptions noted.\n\nNo exceptions noted.\n\nCC6.2#6: No exceptions noted.\n\nNo exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ], "ksiTests": [], "ksiEvidence": [] }, { "ksiId": "KSI-IAM-APM", "ksiImplementationStatus": "Implemented", "ksiImplementation": [ "Liferay SaaS uses Okta Directory, a component of Okta GHC, to implement Multifactor Authentication controls.", "The Identity Team configures Liferay SaaS to require Multi-factor Authentication (MFA) using both [Identity Management: @Okta Directory] and [Multi-Factor Authentication: @Security keys] as the second factor for authentication. This applies to all logical access to Liferay SaaS, including privileged sessions and remote access." ], "ksiRemarks": "", "ksiValidation": [], "ksiAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC6.1#3: Inquired of the Senior Manager, Information Security regarding the authentication of a user to GCP to determine that network users were authenticated via SSO.\n\nObserved the authentication of a user to GCP to determine that GCP users were authenticated via SSO.\n\nInspected the GCP user listing and password configurations to determine that GCP users were authenticated via SSO.\n\nCC6.1#15: Inquired of the Senior Manager, Information Security regarding the authentication of a user to the production servers to determine that production servers users were authenticated via SSO.\n\nObserved the authentication of a user to the production servers to determine that production servers users were authenticated via SSO.\n\nInspected the production server user listings and password configurations to determine that production server users were authenticated via SSO.\n\nCC6.1#19: Inquired of the Information Security Program Manager regarding the authentication of a user to the production databases to determine that production databases users were authenticated via individually assigned user accounts and passwords.\n\nObserved the authentication of a user to the production databases to determine that production databases users were authenticated via SSO.\n\nInspected the production database user listings and password configurations to determine that production databases users were authenticated via SSO.\n\nCC6.1#24: Inquired of the Senior Manager, Information Security regarding production application access to determine that production application administrative access was restricted to authorized personnel.\n\nObserved a user login to the production application to determine that production application users were authenticated via SSO.\n\nInspected the production application user listing and password configurations to determine that production application users were authenticated via SSO.\n\nCC6.1#30: Inspected the encryption configurations for data in transit and to determine that server certificate-based authentication was used as part of the TLS encryption with a trusted certificate authority.\n\n**Result**\n\nCC6.1#3: No exceptions noted.\n\nNo exceptions noted.\n\nNo exceptions noted.\n\nCC6.1#15: No exceptions noted.\n\nNo exceptions noted.\n\nNo exceptions noted.\n\nCC6.1#19: No exceptions noted.\n\nNo exceptions noted.\n\nNo exceptions noted.\n\nCC6.1#24: No exceptions noted.\n\nNo exceptions noted.\n\nNo exceptions noted.\n\nCC6.1#30: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ], "ksiTests": [], "ksiEvidence": [] }, { "ksiId": "KSI-INR-RIR", "ksiImplementationStatus": "Implemented", "ksiImplementation": [ "The Incident Response Admin manages [Incident Response Plan: @Incident Response Plan] and updates the plan at least annually to ensure the [Incident Response Process: @Incident Response Process] is consistently applied across the #THIS ORGANIZATION. Changes to Liferay SaaS affecting the [Incident Response Plan: @Incident Response Plan] are included in updates, which also address concerns or difficulties during implementation, execution, or testing.\n\nTo better ensure the [Incident Response Plan: @Incident Response Plan] is helping meet #THIS ORGANIZATION incident response objectives, the Incident Response Admin reviews these key metrics:\n\n- Number of alerts fired over x days\n\n- Number of requests received over x days\n\n- Number of investigations conducted over x days\n\n- Number of alerts closed over x days\n\n- Number of requests closed over x days\n\n- Number of investigations closed over x days\n\n- Number of hours spent on alerts, requests, and investigations\n\n- Number of tickets assigned by type and source\n\n- Number of discovery tickets created, closed\n\n- Number of false positive alerts over time, by type\n\n- Tickets closed per Affected User Department\n\n- Mean Time to Respond\n\n- Mean Time to Resolve\n\n- Mean Time to Close", "[Incident Response Plan: @Incident Response Plan] provides a detailed roadmap for implementing incident response in #THIS ORGANIZATION, with assigned roles and responsibilities. The [Incident Response Plan: @Incident Response Plan] defines reportable incidents and assigns a severity level based on the incident characteristics." ], "ksiRemarks": "", "ksiValidation": [], "ksiAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC7.3#3: Inspected the revision history of the incident response policies and procedures to determine that the incident response and escalation procedures were reviewed at least annually for effectiveness.\n\nCC7.2#23: Inspected the security committee meeting minutes for a sample of months to determine that management reviewed reports on an annual basis summarizing incidents, root cause of incidents, and corrective action plans and as part of the review, management identified the need for system changes and implementation of additional controls based on incident patterns and root causes.\n\nCC2.2#15: Inspected the incident response policy and the incident response and notification procedure to determine that documented incident response and escalation procedures for reporting security incidents were in place to guide users in identifying, reporting and mitigating failures, incidents, concerns, and other complaints, and are subject to annual reviews.\n\nCC7.4#11: Inspected the incident response policies and procedures to determine that documented incident response and escalation procedures were in place to guide personnel in addressing the threats posed by security incidents.\n\nCC7.4#9: Inspected the incident response policies and procedures to determine that roles and responsibilities for the design, implementation, maintenance, and execution of the incident response program were defined and documented.\n\n**Result**\n\nCC7.3#3: No exceptions noted.\n\nCC7.2#23: No exceptions noted.\n\nCC2.2#15: No exceptions noted.\n\nCC7.4#11: No exceptions noted.\n\nCC7.4#9: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ], "ksiTests": [], "ksiEvidence": [] }, { "ksiId": "KSI-SVC-SIN", "ksiImplementationStatus": "Implemented", "ksiImplementation": [ "All services/products within Liferay SaaS use FIPS-validated encryption for customer information in transit and at rest. Authorized validation component details can be found in the Cryptographic Modules Table.", "All authentication mechanisms to cryptographic modules, including those in Liferay SaaS, [Identity Management: @Okta Directory], and [Privileged Access Management: @GCP IAM], use FIPS 140-2 validated AES-256 encryption algorithms. [Operating System: @Google Container Optimized OS running gVisor] crypto modules also use AES-256 and are FIPS validated and listed in the NIST Cryptographic Module Validation Program (CMVP)." ], "ksiRemarks": "", "ksiValidation": [], "ksiAssessment": [ "# Step 1\n\n## Result\n\n**Test performed**\n\nCC6.1#31: Inspected the encryption configurations for data at rest to determine that passwords and production data was stored in an encrypted format using software supporting the AES.\n\nCC6.6#5: Inspected the encryption configurations and digital certificates to determine that TLS and other encryption technologies were used for defined points of connectivity.\n\nCC6.6#6: Inspected the encryption configurations for data in transit and digital certificates to determine that transmission of digital output beyond the boundary of the system was encrypted.\n\nCC6.7#15: Inspected the encryption configurations for an example backup media to determine that backup media was stored in an encrypted format.\n\nCC6.1#32: Inquired of the Senior Manager, Information Security regarding the encryption keys to determine that encryption keys were required to be protected during generation, storage, use, and destruction.\n\nInspected the encryption policies and procedures and cryptographic keys management software to determine that encryption keys were required to be protected during generation, storage, use, and destruction.\n\nCC6.6#7: Inquired of the Senior Manager, Information Security regarding access to stored data to determine that logical access to stored data was restricted to authorized personnel.\n\nInspected the database user listing and access rights to determine that logical access to stored data was restricted to authorized personnel.\n\nC1.1#2: Inquired of the Cloud Operations Administrator regarding access to confidential information and appropriateness of the database administrators (DBAs) to determine that confidential information was maintained in locations restricted to those authorized to access.\n\nInspected the access permissions for an example file marked as confidential, the organizational chart and the production database user and administrator listing to determine that confidential information was maintained in locations restricted to those authorized to access.\n\nCC6.5#3: Inspected the data disposal and destruction policies and procedures and the supporting service ticket for a sample of requests to dispose of data to determine that data that was no longer required was disposed of and rendered unreadable to meet the entity’s objectives.\n\n**Result**\n\nCC6.1#31: No exceptions noted.\n\nCC6.6#5: No exceptions noted.\n\nCC6.6#6: No exceptions noted.\n\nCC6.7#15: No exceptions noted.\n\nCC6.1#32: No exceptions noted.\n\nNo exceptions noted.\n\nCC6.6#7: No exceptions noted.\n\nNo exceptions noted.\n\nC1.1#2: No exceptions noted.\n\nNo exceptions noted.\n\nCC6.5#3: No exceptions noted.\n\n## Details\n\n- **Method**: Examine\n- **User**: null\n- **Status**: Pass" ], "ksiTests": [], "ksiEvidence": [] } ] }