Loading...
Loading...
Loading...
Cymmetri Reports is a comprehensive reporting feature that provides valuable insights into user, application, and administrator-related data within the Cymmetri platform. With a range of reports at the administrator's disposal, the administrator can monitor user activities, application access, and administrative actions efficiently.
Cymmetri Reports offers a total of 20 different reports. These reports help the administrator track and manage different aspects of your Cymmetri environment. These reports can be roughly categorized into user-related, application-related, administrator-related, and contract/employee-related sections as shown below:
User Reports
Cymmetri Users Report
Domain Admin Access Report
Recent Hires Report
Sunset User Report
Terminated Users Report
Users Without Reporting Managers
Cymmetri Usage Report
User Login Report
Application Reports
Application Access
Application Assignment Report
Provisioning Report
Unused Roles Report
Application Usage Report
MFA Usage Report
Most Active Users Report
Administrator Reports
Cymmetri Administrators
Cymmetri Audit Report- Log of events/actions performed within Cymmetri.
Contract and Employee Reports
Contractors with upcoming contract end date
Employee's with upcoming contract end date
Terminated Contractors Reports
Terminated Employees Report
Risk Based Reports
Aggregate Risk Report
Application Risk Report
Example view of a report
An administrator, has the option to email reports to him/herself using the Email Report Option:
Also administrator can schedule automatic email delivery of periodic reports to specific users or recipients at regular intervals. This ensures that critical information is consistently delivered to the right people.
To further tailor the reports to specific needs, Cymmetri Reports allows the administrator to filter out certain columns. This feature enables the administrator to focus on the most relevant data and eliminate unnecessary information from the reports.
You can refine the data within the reports by applying specific parameters tailored to each report's requirements.
For specific reports you can also filter on the basis on risk type, custom attributes and other crucial parameters.
Cymmetri Reports empowers administrators to make informed decisions, track user activities, and efficiently manage the Cymmetri environment.
Explore the reports, use the email and scheduling features, and customize the reports through column filtering to get the most out of this powerful reporting tool.
Risk assessment of users in Cymmetri involves evaluating the potential risks associated with user access and actions within the Cymmetri platform. This assessment helps in identifying and mitigating risks to ensure the security and integrity of the system.
The risk calculations are done based on various Cymmetri and AD metrics. A list of these metrics can be seen here:
Cymmetri offers in-depth insights into user risks. To view this information, navigate to Insights > Risks.
Cymmetri allows Aggregate Risk Scoring to offer a holistic view of security risks across various organizational levels, such as by manager, department, location, or company-wide. Below is a structured approach to profiling and organizing these risk scores:
Risk Score Calculation: The solution must aggregate individual user and role-based risks to produce higher-level risk scores that reflect the overall security posture across different tiers of the organization.
Formula: Risk scores can be calculated using weighted factors such as:
Severity of risks (e.g., High, Medium, Low)
Number of violations
Impact on critical business applications
The system should generate reports that profile risks across several organizational dimensions:
Manager Name: Identify managers overseeing specific users or teams.
Team Risk Score: Aggregate risk score for the manager’s team, considering users' access rights, policy violations, SoD violations, and role mismanagement.
Manager’s Accountability: Identify potential risks related to the manager’s own access and their team's overall risk exposure.
Top Risks by Team: Highlight the most critical risks faced by each manager’s team.
Department Name: Clearly identify departments (e.g., Finance, HR, IT).
Department Risk Score: Aggregate risk for the entire department by analyzing access patterns, policy violations, and SoD conflicts among members.
Risk Breakdown:
Percentage of High, Medium, and Low risks by department
Number of roles and permissions posing risks within the department
Key Applications at Risk: Applications within the department that are highly exposed to security threats
Location Name: Identify office locations or regions where users are based.
Location Risk Score: Aggregate risk based on geographic considerations, accounting for localized compliance and security issues.
Risk Distribution: Display geographic risk scores to indicate which locations have the highest or lowest security vulnerabilities.
Overall Risk Score: Present a high-level, company-wide risk score reflecting the organization’s overall security posture.
Company-wide Risk Distribution:
Total number of high, medium, and low risks across the company
Key risk contributors (departments, managers, locations)
Top 10 Critical Risks: Highlight the most urgent risks requiring immediate attention
Historical Trend: Display changes in the company-wide risk score over time, such as improvements post-policy enforcement or increases due to new vulnerabilities.
Severity Levels: Each profiled risk should be categorized as:
High Risk: Critical and requires immediate remediation.
Medium Risk: Significant but less urgent.
Low Risk: Monitor, but not immediately critical.
Prioritization: Focus on departments or teams with higher aggregate risks for expedited action.
For each profiled risk, provide:
Mitigation Actions: Suggestions to reduce the risk (e.g., removing unnecessary roles, enabling multi-factor authentication).
Responsible Entity: Identify who (manager, department, or location) should take action to resolve the risk.
Remediation Deadline: Suggested deadlines for risk mitigation.
The IAM solution should feature a dashboard to visualize aggregate risk scores across the organization. Key dashboard features should include:
Heat Maps: Color-coded maps displaying risk scores by location, department, or manager.
Bar Charts and Graphs: Visual representation of risk distribution and trends over time.
Filter Options: Allow users to filter views by department, location, manager, or specific applications for detailed analysis.
Report Scheduling: Automatically generate and distribute risk score reports at regular intervals (e.g., monthly, quarterly).
Stakeholder Distribution: Tailor reports for managers, department heads, compliance officers, and the CISO, based on their level of responsibility.
Compliance Checks: Align risk scoring with compliance frameworks (e.g., SOX, GDPR, HIPAA) to highlight areas where the organization may be falling short of regulatory requirements.
Audit Trail: Provide detailed logs of risk score changes, access adjustments, and mitigation actions for audit purposes.
Cymmetri's Risk scoring offers both a detailed and high-level overview of security risks, empowering stakeholders to make informed decisions and prioritize security efforts across the organization.
The Dashboard section provides a comprehensive overview of the current risk status across the Cymmetri platform. By visualizing key metrics and trends, it allows for quick identification of high-risk areas and users.
The dashboard features a "Risk Stats" section, presenting a graphical display of the number of users categorized by risk level—High, Medium, and Low. This visualization represents data synced across various days within a specified date range.
It also shows a section where it shows various risk calculation metrics. This section outlines various user activities and status changes observed over the past 7 days, as well as upcoming account expirations in the next 30 days.
User cannot change the password in AD: Users that are restricted from changing their passwords, which could affect user security and compliance.
User Recently Created last 7 days: New user accounts have been created in last 7 days.
User Recently Modified last 7 days: Accounts that have been modified in last 7 days in any ways.
User Recently Deleted last 7 days: Users whose accounts that have been removed in last 7 days. Monitoring deletions is crucial for understanding changes in user access and potential security risks.
User Account Expires next 30 days: Users whose accounts are set to expire within the next 30 days. These need to be reviewed to determine if extensions are necessary.
User recently not logged in last 7 days: Users whose accounts that have not had any login activity in the last 7 days. This could indicate unused accounts or potential issues with user access.
User recently locked last 7 days: Users whose accounts that have been locked out due to incorrect password attempts or other security protocols in the last 7 days.
Each of these section has a View link which opens up a modal that further shows user details for each of these metrics as shown below:
The risk configuration section is used to configure Active Directory which is later used to sync Active DIrectory risk parameters.
Some of the basic configurations fields are:
Name: Risk Configuration Name. For eg. AD Risk Config
Description: A general description about the Risk Comfiguration
IdM Repository Field: A unique identifier on Cymmetri side. For eg. login
Source Attribute Name: A unique identifier from Active Directory. For eg. sAMAccountName
Next we need to do User and Server Configuration
Consists of configuring the connector server. Enter the IP address of the host server and its password. The rest of the fields come pre-filled with default values; you can change them according to your use case. Next, click on the save configuration button.
Mentioned below are the field descriptions:
Note: Ensure that the bundle used is for Active Directory Risk configuration is adanalytics-1.0-bundle.jar and the connector server version is atleast 1.5.2.0
User Configuration consists of all user settings like domain name, search filter, etc. We can also configure an OU (Organisational Unit) in this window.
The section allows administrators to view a list of synchronization events that have occurred for Active Directory (AD) Risk Details, along with the ability to access a detailed Risk Assessment Report for high-risk users.
The Risk Assessment History page displays a list of synchronization events for AD Risk Details. The following information is displayed for each synchronization event:
Name: The name of the synchronization event.
Description: A brief description of the synchronization event.
Start at: The start time of the synchronization event.
End at: The end time of the synchronization event.
Start Mode: The start mode of the synchronization event (MANUAL or AUTO).
End Mode: The end mode of the synchronization event (MANUAL or AUTO).
Status: The status of the synchronization event.
Actions: The Actions section contains a View button, which allows users to view the Risk Assessment Report for the synchronization event.
Risk Assessment Report
The Risk Assessment Report provides detailed information about all users associated with the synchronization event. The following information is displayed for each user:
Name: The name of the user.
SAM Account: The Security Account Manager (SAM) account name of the user.
Mail: The email address of the user.
Type: The type of user.
Risk Score: The risk score assigned to the user.
View Risks: A View Risks button which allows users to view the Risks for a particular user.
View Risks Button
The View Risks button is enabled only for high-risk users and allows administrators to view various AD and Cymmetri metrics used for risk calculation. This button provides additional insight into the factors contributing to the user's high-risk status.
Risk Details Page
The Risk Details page displays detailed information about a specific user's risk assessment. The following information is displayed:
Sam Account Name: The Security Account Manager (SAM) account name of the user.
Display Name: The display name of the user.
Mail: The email address of the user.
User Type: The type of user (e.g., Employee).
Risk Score: The risk score assigned to the user.
Additionally, a table is provided that lists the risk type name (ADProcessor or CymmetriUserProcessor), description, and risk score for each risk associated with the user.
Cymmetri recommends risk mitigation actions for high risk users, for various actions like monitoring of user activity, review certifications, and remediation of various policy violations
Cymmetri provides a framework for managing risk arising for application access to organization users. Broadly, the risk is quantified on the basis of Qualitative and Quantitative measures
This is a risk that is identified from the knowledge of the system. This means that even in absence of the Enterprise Role model or mapping of activities or tasks or processes to the users, a certain risk value may still be assigned to the users, purely based on the application roles based on the COSO framework (i.e. admin / maker / checker / read only) and applications assigned to them.
The qualitative risk calculation will be based on: • The number of applications assigned to a particular user, the risk associated with the application, & • The risk associated with the COSO type of the application role.
This is a risk that is identified from the specific classification of application roles based on High, Medium and Low risk. The risk classification is thus based on users having roles assigned to them.
To configure the risk parameters, it is necessary to categorize the application level risk as well as role level risk.
Cymmetri enables trigerring of ad-hoc user certification based on parameters as mentioned below:
User's current risk level/ score
Duration between certification cycles
Manual execution of certification task by manager/ admin
The above mentioned configurations assist the approving / certifying authorities to have a nuanced view of the user, their entitlements and the risks associated as per the existing policy configurations in Cymmetri. Refer the Access Certification process for more details.
Considering Cymmetri has the ability to identify the potential risks associated with user identities and their entitlements from the system, the system can thus provide relevant risk assessment.
The parameters influencing the risk measures are several-
User Profile / High Risk Users
Application Access Reviews
Groups assigned to user
Role assigned to user
IT Roles provisioned to user
Policy violations including SoD
Anomaly Detection
Refer Cymmetri Risk Reporting video
The Identity and Access Management (IAM) solution generates Defined Security Risks Report by Application with the following core elements:
Application Summary
Application Name
Application Owner
User Base
Risk Identification
Access Control Risks
Excessive Privileges
Unauthorized Access
Inactive Accounts (dormant access)
Role and Permission Risks
Redundant Roles
Orphaned Roles
Role Accumulation
Segregation of Duties (SoD) Violations
Policy Non-Compliance
Password Policies
Multi-Factor Authentication (MFA)
Compliance Gaps
Risk Scoring
Affected Users
Name and Role
Access Level
Historical Trends
Risk Evolution
Resolved Risks
Recommendations
Remediation Actions
Role optimization or recertification
Removing excess privileges
Enforcing stronger password policies or MFA
Addressing SoD violations through role restructuring
Deadline for Action
Integration with Incident Management / Service Desk
Incident Ticketing
Status Tracking
Audit Logs
Access Changes
Violation Occurrences
Reports
Export Options - Excel, PDF, CSV
Automated Distribution
| Field Name | Description |
|---|---|
| Field Name | Description |
|---|---|
Host server
The IP address of the host server
Server port
Port of the host server
Server Password
Host Server password
Server Connector Timeout
Timeout of the connector server in milliseconds
Server Connector UseSSL
Connector server SSL configuration
Entry object classes
Object classes to which the Account class is mapped
Base contexts to synchronize
Display names used for Active Directory synchronisation to Cymmetri, such as domain controller name
Credentials
Admin password to connect to Active Directory
Default id Attribute
Default attribute Id
Failover
An array of LDAP URLs specifying failover servers. If the connector cannot make a connection to the server specified in the host property, it will try connecting to these failover servers in the specified order.
Custom user search filter
Search filter used to search accounts
Default people container
Default people container can be used during create operation in case of entry DisplayName is not explicitly mentioned
Host Server
Active Directory server hostname that would connect to Cymmetri
Object classes to synchronize
User object classes to synchronize. The connector ignores any changes if it cannot find modified entry object classes in this property.
Page size
Get users from Active Directory with the provided size
Pageable result
Get users from Active Directory with the provided size pageable result
Server port
Port of the Active Directory connector server
Principal
Admin username of the Active Directory
Retrieve deleted users
Indicate if deleted users must be synchronised also.
Server Connector UseSSL
Connector server SSL configuration
Trust all certs
Indicative if all server certificates can be trusted
UID attribute
Unique Identifier Attribute
Base context for user entry searches
Display the Name of OU (Organization Unit), Root domain or Root controller required for user entry search
User search scope
The scope could be a subtree or object for user search
Cymmetri is built in accordance to industry regulations and guidelines.
Below are the IRDAI relevant control objectives.
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
The General Data Protection Regulation (GDPR) imposes strict requirements on organizations that process personal data. This includes specific guidelines related to Identity and Access Management (IAM).
Data Minimization
Lawful Processing
Data Subject Rights
Accountability
Strong authentication: Implement strong authentication mechanisms, such as multi-factor authentication (MFA), to protect against unauthorized access.
Access control: Implement robust access control measures to ensure that only authorized individuals can access personal data.
Data encryption: Encrypt personal data both at rest and in transit to protect against unauthorized access and disclosure.
Regular reviews: Conduct regular reviews of access rights to ensure they remain appropriate and necessary.
Incident response plan: Have a plan in place to respond to data breaches and other security incidents.
Data retention policies: Establish clear data retention policies that align with the GDPR's requirements.
Consent management: If relying on consent as a legal basis for processing, ensure that consent is freely given, specific, informed, and unambiguous.
By adhering to these guidelines, organizations can ensure that their IAM practices comply with the GDPR and protect the privacy and rights of individuals.
The Health Insurance Portability and Accountability Act (HIPAA) sets standards for the privacy and security of Protected Health Information. This includes specific requirements related to Identity and Access Management (IAM).
Administrative safeguards: Implement administrative procedures to safeguard PHI, including risk assessments, security awareness training, and incident response plans.
Physical safeguards: Implement physical measures to protect PHI, such as access controls, surveillance systems, and disaster recovery plans.
Technical safeguards: Implement technical measures to protect PHI, such as access controls, encryption, and audit trails.
Business associate agreements: If you work with business associates that handle PHI, ensure that they have appropriate safeguards in place and enter into business associate agreements.
Notify affected individuals: If a breach of PHI occurs, you must notify affected individuals without undue delay.
Report to HHS: In certain cases, you must also report the breach to the Department of Health and Human Services (HHS).
Incident response: Develop and implement an incident response plan to address security breaches and data breaches.
Access controls: Implement robust access controls to ensure that only authorized individuals can access PHI.
Authentication: Require strong authentication methods, such as multi-factor authentication, to prevent unauthorized access.
Authorization: Assign appropriate access privileges based on job functions and roles.
Password management: Implement strong password policies and enforce regular password changes.
Data encryption: Encrypt PHI both at rest and in transit to protect against unauthorized access and disclosure.
Audit trails: Maintain audit trails to track access to PHI and identify potential security breaches.
Risk assessments: Conduct regular risk assessments to identify potential vulnerabilities and take appropriate measures to mitigate them.
By adhering to these guidelines, organizations can ensure that their IAM practices comply with HIPAA and protect the privacy and security of PHI.
The Sarbanes-Oxley Act (SOX) is a U.S. federal law that sets standards for financial reporting and corporate governance. While it doesn't explicitly mention Identity and Access Management (IAM), its focus on internal controls and financial reporting has significant implications for IAM practices.
Segregation of duties: Ensure that there is a separation of duties to prevent conflicts of interest and fraud. For example, individuals who have access to create or modify records should not also have the authority to approve or authorize transactions.
Access logs: Maintain detailed access logs to track user activity and identify unauthorized access.
Change management: Implement a formal change management process to review and approve changes to systems and access controls.
Regular reviews: Conduct regular reviews of access rights to ensure they remain appropriate and necessary.
Incident response: Have a plan in place to respond to security breaches and other incidents.
Accurate and reliable data: Ensure that financial data is accurate and reliable by implementing appropriate access controls and data integrity measures.
Management oversight: Management should oversee IAM practices and ensure that they are effective in preventing unauthorized access and data manipulation.
Documentation: Document IAM policies and procedures to demonstrate compliance with SOX requirements.
User provisioning and deprovisioning: Establish clear procedures for adding and removing users from systems, ensuring that access is granted and revoked promptly.
Password management: Implement strong password policies and enforce regular password changes.
Privilege escalation: Limit the ability of users to escalate their privileges, preventing unauthorized access to sensitive systems or data.
Monitoring and alerting: Implement monitoring and alerting systems to detect unusual activity or potential security threats.
Third-party access: If you work with third-party vendors or contractors, ensure that they have appropriate safeguards in place to protect your data.
By adhering to these guidelines, organizations can demonstrate compliance with SOX and strengthen their internal controls related to identity and access management.
The Payment Card Industry Data Security Standard (PCI DSS) outlines requirements for organizations that handle cardholder data. This includes specific guidelines related to Identity and Access Management (IAM). Here are some key points to consider:
Assign unique IDs: Assign unique identifiers to each person with authorized access to cardholder data.
Limit access: Restrict access to cardholder data to only those individuals who need it to perform their job functions.
Regular reviews: Conduct regular reviews of access rights to ensure they remain appropriate and necessary.
Least privilege principle: Grant individuals only the minimum privileges necessary to perform their job functions.
Identify components: Assign unique identifiers to all system components that process, store, or transmit cardholder data.
Track access: Track access to system components to identify unauthorized access.
Secure areas: Restrict physical access to areas where cardholder data is processed, stored, or transmitted.
Access controls: Implement physical access controls, such as locked doors and security cameras.
Access logs: Maintain detailed access logs to track user activity and identify unauthorized access.
Monitoring: Implement monitoring systems to detect unusual activity or potential security threats.
Alerting: Configure alerts to notify appropriate personnel of suspicious activity.
Password policies: Implement strong password policies, including minimum length, complexity requirements, and regular password changes.
Authentication: Require strong authentication methods, such as multi-factor authentication.
Privilege escalation: Limit the ability of users to escalate their privileges, preventing unauthorized access to sensitive systems or data.
Penetration testing: Conduct regular penetration testing to identify vulnerabilities in access controls.
Vulnerability scanning: Use vulnerability scanning tools to identify and address security weaknesses.
By adhering to these guidelines, organizations can demonstrate compliance with PCI DSS and protect cardholder data from unauthorized access.
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | Cymmetri Coverage |
|---|---|
| Key Points | |
|---|---|
The Information Owner shall only classify information assets within their purview using one of the following four classification levels: Public, Internal, Restricted, Confidential. Classification levels shall be defined based on the information asset’s relative risk, value, and sensitivity.
Cymmetri will allow the right user to access the right application with the right context based on the access policies defined in Cymmetri platform. Applications can internally manage the data classification for asset's risk management.
All Information assets should have a designated owner, Owner may delegate ownership to others, but will be accountable for the same
Cymmetri will protect access to application resources by allowing the appropriate user to the required resources. The information owner may allow delegation if allowed through Cymmetri access policies.
A User-ID or account shall be assigned to each individual to authorize a defined level of access to information assets and shall be protected by authenticating the user to the User-ID upon requesting access.
Cymmetri IDAM allows creation and maintenance of clean user identities for purpose of authorization to resources and authentication to applications.
The use of generic and group User-IDs shall be avoided wherever possible. Wherever there is no alternative available / it is absolutely essential a group account shall be used; however, it shall follow the Exception grant and risk assessment methodology requiring the prior authorization of the appropriate authorities and clear accountability to one individual (Group ID owner) shall be established. The use of Group-ID shall be short term in nature having an expiration date
Cymmetri principally works with one-user-one-identity. However, for exception cases, Cymmetri allows mapping of generic-IDs to specific individual accounts and maintain the details of all access events using such generic accounts. Cymmetri platform grants access based on defined workflows for access to generic accounts along with periodic access reviews as well as defined end-of-access date for such scenarios.
An owner shall be identified for every generic User-ID created and the owner shall be held accountable for all actions associated with the generic User-ID. Where it is required for a generic User-ID to be shared between multiple individuals, alternative solutions for assigning and ascertaining accountability at all times shall be evaluated for feasibility and shall be implemented.
Cymmetri principally works with one-user-one-identity. However, for exception cases, Cymmetri allows mapping of generic-IDs to specific individual accounts and maintain the details of all access events using such generic accounts. Cymmetri platform grants access based on defined workflows for access to generic accounts along with periodic access reviews as well as defined end-of-access date for such scenarios.
Access to Organization’s environment such as the network shall be granted only upon intimation received from HR. All users shall be granted access to the information systems and services through a formal user registration process that shall include the approval of access rights from authorized personnel before granting access.
Cymmetri IDAM manages all users through
Identity Hub which maintains all organization
users including employees and third-party users.
Access grants to enterprise resources shall be
applied through Cymmetri Provisioning Rules
framework.
All users shall follow a formal de-registration process for revocation of access to all information systems and services which shall include automated or timely intimation and revocation of access rights. Intimation for revocation of access rights shall come from HR. A confirmation of the access revocation shall be sent to HR as a part of the exit clearance process.
Cymmetri IDAM can automatically remove all access entitlements for a user based on source system of truth & internal access policies to ensure clean exit process.
Levels of access granted to all Users shall enforce segregation of duties and adhere to the “need to know” principle. Where segregation of duties cannot be enforced by logical access controls, other non-IT-related controls shall be implemented.
Cymmetri IDAM allows configuration of an organizations business policies and tasks w.r.t. to access to application and their roles to establish SoD.
An initial password shall be provided to the users securely during the user creation process and the system shall be configured to force the users to change the initial password immediately after the first logon.
Cymmetri enforces password policy on its users such as creating a new password after first logging into the system.
Appropriate procedures shall be put in place for storing and management of administrative passwords for critical information systems. All user passwords shall be encrypted while in transmission and storage.
Cymmetri securely manages all passwords by the use of strong cryptography controls. This ensures secure relay and storage of such information.
The password requirements for all user accounts shall follow the password standards as defined in the Password Standard. Any exceptions to the password standard shall follow the Exception grant and risk assessment methodology requiring the prior authorization of the appropriate authorities and counter measures shall be implemented to mitigate the resulting risk.
Cymmetri policy enforces password for all users. For varying use cases, Cymmetri can allow a differential password policy for certain users which can be enforced using appropriate controls in place such as approvals.
Users shall be required to change their passwords once in 45 days
Part of default Cymmetri password policy
A record of previously used passwords shall be maintained to prevent re-use. Further, password files shall be stored separately from application system data.
Part of default Cymmetri password policy. All passwords are stored separately and not part of user profile or application data.
In case of transfer of an employee from one function to another, access rights of the user shall be revoked for previous functional role and access need to be provided for new functional role.
Cymmetri Provisioning Rules allow for setting up access grants based on role / attributes associated with user. On the event of a transfer, Cymmetri shall automatically remove access to previous entitlements and provision to new roles associated with the user.
User authorization mechanisms at each level shall be independent of authorization at a previous or subsequent level – for example, applications shall perform assessment of user authorization request independent of the operating system authorization process
All authorization events in Cymmetri are independent and not derived based on previous or next approver associations.
Users shall be authenticated and authorized by a domain policy server.
Cymmetri allows federated identity management principles, and thus, shall use an external identity provider for authentication such as AD or LDAP.
Access to all endpoints and applications shall be permitted only after authorization of the user credentials by the host operating system or the application itself
Cymmetri allows for dual authentication strategy such as application access or during device authentication by user. The authentication policy can also force Multi-factor authentication to ensure strong authentication for all users.
If the authorization request comes from a Organization owned asset (device/network), single factor authentication will suffice. In case the authorization request comes from a non Organization asset (device/network) two-factor authentication will be mandatory.
Cymmetri IDAM has configurable MFA options and rules to invoke strong authentication principles.
Applications hosted on the Cloud shall accept a user authorization record validated by a Organization-owned authorization service or require two factor authorization
Cymmetri enables organizations to specify the authentication source as part of the authentication policy. The policy will also invoke MFA based on rules defined or adaptive controls available in Cymmetri.
Users shall be required to re-authenticate themselves after a specific period of inactivity.
Cymmetris' session management asks users to re-authenticate themselves after a given period of inactivity.
Activity from all logons with Privileged User ID shall be securely logged.
All authentication requests are logged in Cymmetri platform.
Account lockout shall be enforced by the log-on process after the retry limit is reached
Cymmetri authentication policy allows account lock and unlock thresholds to be defined.
Log of unsuccessful and successful attempts shall be maintained.
In Cymmetri, all access logs are maintained for audit purpose with essential data points - who, when, what, and from where
The log-on process shall terminate inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the organization’s security management or on mobile devices
The session management principle enforces the timeout of the session from Cymmetri and compliant SSO applications integrated with Cymmetri.
Authorizations for privileged access rights shall be reviewed at more frequent intervals and changes to privileged accounts shall be logged for periodic review.
Cymmetri IDAM allows Access Governance through predefined campaigns which allow the approving authority to validate access rights of user, including privileged accounts.
Remote access request for third party vendor/consultant shall be raised by the Organization Employee responsible for the vendor /consultant engagement along with proper business justification. The request needs to be approved by sponsoring functional manager, Head – IT and Group CISO. If access is provided from non Organization endpoints an exception shall be taken in this regards Head-IT and Group CISO.
Cymmetri's configurable workflows allow organizations to setup user request and approvals process for granting of access to application resources on a time bound manner. This control ensures check of appropriateness of access requests as well as maintains an audit log of all such grants (or reject of grant) by the approving authorities
An expiration of not more than 15 days or lesser shall be placed on all third party user-IDs unless appropriate approval is given. Expiration of IDs will occur in the authenticating database. After the expiration, third parties who wish to continue working for Organization should obtain approval in order to regain the User-ID.
The Time based access policy for granting access to users in Cymmetri controls access for any type of user. The user may be allowed to extend access based on appropriate approvals for such extension of access to specified applications.
Remote access solutions must support strong, end-to-end encryption as mentioned in Organization’s policy for Cryptographic Controls.
Cymmetri employs strong cryptographic controls which are at par or exceed standard encryption methodologies.
A remote log-on procedure shall be designed with consideration of encryption of information during its transmission. A secure network channel shall be established for remote access.
All access to privileged resources are over secure channels with appropriate authentication principles ensuring secure transmission of data.
Organization security solutions and controls shall not be disabled or circumvented.
Cymmetri access controls do not allow circumvention. In case of emergencies, a break-glass type scenario allows emergency access to critical assets as a one-time event.
Remote Access System Owners shall maintain evidence of all requests for granting remote access
In Cymmetri, all access logs are maintained for audit purpose with essential data points - who, when, what, from where
All evidence for granting, revoking, or changing remote access privileges shall be maintained in a repository
With detailed audit and reporting capabilities, Cymmetri ensures access to privileged resources is logged for to ensure compliance
On a monthly basis, the system owner’s shall ensure that the accounts active within the Remote access solutions are accurate. All discrepancies shall be resolved quickly
Cymmetri IDAM allows Access Governance through predefined campaigns running at required intervals for regular users as well as privileged users to mapped approving authority, thus ensuring the active users continue to have appropriate access to resources
Access to program source code and associated items (such as designs, specifications, verification plans and validation plans) shall be strictly controlled
Cymmetri's access controls allow appropriate users to authenticate with entitled resources thus ensuring strict controls
Program source libraries shall not be held in operational systems. The program source code and the program source libraries shall be managed according to established procedures.
Cymmetri platform is implemented using a containerized deployment standard. This ensures product source code and libraries are not exposed directly to and cannot be changed / modified.
IT Support personnel shall not have unrestricted access to program source libraries.
Cymmetri's access controls allow appropriate users to authenticate with entitled resources thus ensuring strict controls
The updating of program source libraries and associated items and the issuing of program sources to programmers shall only be performed after appropriate authorization has been received.
Cymmetri platform is a standard product following agile methodology for code changes which adhere to a change management process for any and all changes to the system.
An audit log shall be maintained of all accesses to program source libraries and program listings shall be held in a secure environment.
Access to Cymmetri source code and configurations can be restricted through appropriate access policies within the platform.
