A
Arden Hecate
Guest
Protecting sensitive information often involves meeting regulatory requirements governing who can see application data and how cryptographic operations are handled. As those requirements evolve, development teams and database administrators need to understand how Progress OpenEdge capabilities support their security needs and what additional work remains within their applications.
That was the focus of our recent webinar, Ask Me Anything: Dynamic Data Masking and FIPS in Action, with Talha Masood, Principal Software Engineer and Product Owner, and Fernando Souza, Distinguished Engineer. Through demonstrations and an extended Q&A, the session explored Dynamic Data Masking (DDM), available in OpenEdge 12.8.3 or newer, and FIPS 140-3 support, introduced in OpenEdge 13.0, along with practical considerations for configuring them. Understanding DDM now enables smoother transition to OpenEdge 13.2, our next LTS, later.
The webinar focused on two key areas: configuring DDM to control access to sensitive fields and preparing database users for a FIPS-enabled OpenEdge 13.0 environment. Evaluating these capabilities now gives teams an opportunity to test masking rules, review password compatibility and identify application changes as they prepare for the next Long-Term Support (LTS) release.
Dynamic Data Masking (DDM) helps organizations limit exposure of sensitive information by obscuring selected database fields for users who are not authorized to see their actual values. Talha explained that DDM uses role-based access control and can support efforts to address privacy and compliance requirements such as GDPR and HIPAA.
DDM provides four masking options: partial, null, literal and default masking. These options allow administrators to conceal part of a value, return a null value, substitute a specified literal or apply the default masking behavior, depending on the field and the intended presentation.
Authorization tags connect user-defined roles to protected database fields. Users with an authorized role can see the actual field values, while other users receive masked values. A role can be associated with multiple authorization tags, allowing administrators to configure access across different groups of sensitive fields.
To use DDM as demonstrated in the webinar, you must be using OpenEdge 12.8.3 or later and have a license installed for the OpenEdge Advanced Security package. Talha also recommended creating a security administrator and explained the separate DDM administrator role, which provides a way to divide security responsibilities from masking configuration.
Configuration begins with identifying the fields that need protection and the users who should be able to view their actual values. Administrators then enable DDM, establish the DDM administrator, create user-defined roles, grant those roles to users and associate authorization tags with the roles and protected fields.
Talha demonstrated this process using the OpenEdge Data Admin Service classes and a sample Employee Information System. The classes provide methods for creating users and roles and managing the relationships needed for DDM configuration, allowing those tasks to be incorporated into administrative tools.
The demonstration highlighted an important distinction between enabling DDM and activating it. After the roles, tags and field masks had been configured, sensitive values remained visible until DDM was activated. Activation was the step that caused the configured masking rules to take effect.
The sample application used three roles: HR, manager and HR manager. Talha configured masks for employee information including pension details, stock purchase information, vacation days and Social Security numbers, then signed in with different users to show how the same application presented different values.
The HR user could view pension information, while the manager could view vacation days and stock purchase information. Other protected fields appeared as literal replacement values. The HR manager role was associated with all three authorization tags and could therefore view all of the sensitive fields used in the demonstration.
Talha explained that masking also applies when protected field values are assigned to program variables or temp-tables, exported to files or passed as parameters. The query processing engine still works with the underlying values, however, which means masking does not change how the database resolves queries.
The Q&A illustrated this behavior with a salary example. A user might receive a masked salary value but still retrieve employee names through a query that filters on a salary range. Teams should account for this kind of behavior when designing how applications expose queries and sensitive information.
The second part of the webinar focused on FIPS, or Federal Information Processing Standards, and FIPS 140-3 support in OpenEdge 13.0. Talha explained that FIPS mode requires a license for the OpenEdge Advanced Security package and is supported in 64-bit OpenEdge installations.
The demonstration examined a migration scenario in which database users moved from an earlier OpenEdge version into OpenEdge 13.0. Their existing passwords had been encoded using a non-FIPS-compliant algorithm, so enabling FIPS mode prevented those users from signing in with their legacy credentials.
Talha used the POLMAN utility to check the FIPS status and enable FIPS mode. Before enabling it, the migrated user could sign in successfully. Afterward, the same login attempt failed, demonstrating why administrators need to review existing credentials as part of migration planning.
To resolve the issue, Talha signed in to the Data Administration tool as a security administrator and changed the affected user’s password. The User Report’s New Password column changed from No to Yes, indicating use of the newer password method, and the user could then sign in while FIPS mode remained enabled.
Fernando explained that DDM operates at the field and role level, rather than the individual record level. If an employee should be able to see only their own sensitive record, the application must implement that record-level restriction.
The presenters also clarified that DDM does not encrypt the underlying database data. Administrative operations such as binary dump and load, database auditing and index activation access actual values without applying the masking rules. Database and security administrators therefore need to manage access to those operations separately.
User accounts do not have to reside in the database, Fernando explained, provided the identity used to connect is correctly associated with the configured roles. Role configuration is maintained per database. Talha noted that Change Data Capture tables inherit masking configuration when created, with administrators able to modify it. He also clarified that DDM does not support character large object (CLOB) fields, which store large amounts of text, or binary large object (BLOB) fields, which store binary data such as images or documents.
The FIPS Q&A reinforced that enabling FIPS mode does not automatically make an entire application or environment compliant. Talha explained that organizations must also evaluate application code, password handling, the operating system, hardware and other relevant components as part of their compliance work.
The webinar demonstrated how DDM and FIPS support address different aspects of OpenEdge security. DDM controls which roles can view sensitive field values, while FIPS mode introduces cryptographic requirements that teams need to consider when preparing applications and migrating existing database users. Explore the OpenEdge Advanced Security package to learn more about the available capabilities and how they can support your organization’s security requirements.
For organizations evaluating these capabilities, the demonstrations provide a practical starting point for understanding configuration, activation and testing. Watch the full on-demand webinar to see both demonstrations and hear the complete Q&A directly from our OpenEdge experts.
Continue reading...
That was the focus of our recent webinar, Ask Me Anything: Dynamic Data Masking and FIPS in Action, with Talha Masood, Principal Software Engineer and Product Owner, and Fernando Souza, Distinguished Engineer. Through demonstrations and an extended Q&A, the session explored Dynamic Data Masking (DDM), available in OpenEdge 12.8.3 or newer, and FIPS 140-3 support, introduced in OpenEdge 13.0, along with practical considerations for configuring them. Understanding DDM now enables smoother transition to OpenEdge 13.2, our next LTS, later.
The webinar focused on two key areas: configuring DDM to control access to sensitive fields and preparing database users for a FIPS-enabled OpenEdge 13.0 environment. Evaluating these capabilities now gives teams an opportunity to test masking rules, review password compatibility and identify application changes as they prepare for the next Long-Term Support (LTS) release.
Controlling Sensitive Data Visibility with Dynamic Data Masking
Dynamic Data Masking (DDM) helps organizations limit exposure of sensitive information by obscuring selected database fields for users who are not authorized to see their actual values. Talha explained that DDM uses role-based access control and can support efforts to address privacy and compliance requirements such as GDPR and HIPAA.
DDM provides four masking options: partial, null, literal and default masking. These options allow administrators to conceal part of a value, return a null value, substitute a specified literal or apply the default masking behavior, depending on the field and the intended presentation.
Authorization tags connect user-defined roles to protected database fields. Users with an authorized role can see the actual field values, while other users receive masked values. A role can be associated with multiple authorization tags, allowing administrators to configure access across different groups of sensitive fields.
Configuring and Activating DDM
To use DDM as demonstrated in the webinar, you must be using OpenEdge 12.8.3 or later and have a license installed for the OpenEdge Advanced Security package. Talha also recommended creating a security administrator and explained the separate DDM administrator role, which provides a way to divide security responsibilities from masking configuration.
Configuration begins with identifying the fields that need protection and the users who should be able to view their actual values. Administrators then enable DDM, establish the DDM administrator, create user-defined roles, grant those roles to users and associate authorization tags with the roles and protected fields.
Talha demonstrated this process using the OpenEdge Data Admin Service classes and a sample Employee Information System. The classes provide methods for creating users and roles and managing the relationships needed for DDM configuration, allowing those tasks to be incorporated into administrative tools.
The demonstration highlighted an important distinction between enabling DDM and activating it. After the roles, tags and field masks had been configured, sensitive values remained visible until DDM was activated. Activation was the step that caused the configured masking rules to take effect.
Seeing Role Based Masking in an Application
The sample application used three roles: HR, manager and HR manager. Talha configured masks for employee information including pension details, stock purchase information, vacation days and Social Security numbers, then signed in with different users to show how the same application presented different values.
The HR user could view pension information, while the manager could view vacation days and stock purchase information. Other protected fields appeared as literal replacement values. The HR manager role was associated with all three authorization tags and could therefore view all of the sensitive fields used in the demonstration.
Talha explained that masking also applies when protected field values are assigned to program variables or temp-tables, exported to files or passed as parameters. The query processing engine still works with the underlying values, however, which means masking does not change how the database resolves queries.
The Q&A illustrated this behavior with a salary example. A user might receive a masked salary value but still retrieve employee names through a query that filters on a salary range. Teams should account for this kind of behavior when designing how applications expose queries and sensitive information.
Preparing for FIPS Mode in OpenEdge 13
The second part of the webinar focused on FIPS, or Federal Information Processing Standards, and FIPS 140-3 support in OpenEdge 13.0. Talha explained that FIPS mode requires a license for the OpenEdge Advanced Security package and is supported in 64-bit OpenEdge installations.
The demonstration examined a migration scenario in which database users moved from an earlier OpenEdge version into OpenEdge 13.0. Their existing passwords had been encoded using a non-FIPS-compliant algorithm, so enabling FIPS mode prevented those users from signing in with their legacy credentials.
Talha used the POLMAN utility to check the FIPS status and enable FIPS mode. Before enabling it, the migrated user could sign in successfully. Afterward, the same login attempt failed, demonstrating why administrators need to review existing credentials as part of migration planning.
To resolve the issue, Talha signed in to the Data Administration tool as a security administrator and changed the affected user’s password. The User Report’s New Password column changed from No to Yes, indicating use of the newer password method, and the user could then sign in while FIPS mode remained enabled.
Questions from the Audience
Fernando explained that DDM operates at the field and role level, rather than the individual record level. If an employee should be able to see only their own sensitive record, the application must implement that record-level restriction.
The presenters also clarified that DDM does not encrypt the underlying database data. Administrative operations such as binary dump and load, database auditing and index activation access actual values without applying the masking rules. Database and security administrators therefore need to manage access to those operations separately.
User accounts do not have to reside in the database, Fernando explained, provided the identity used to connect is correctly associated with the configured roles. Role configuration is maintained per database. Talha noted that Change Data Capture tables inherit masking configuration when created, with administrators able to modify it. He also clarified that DDM does not support character large object (CLOB) fields, which store large amounts of text, or binary large object (BLOB) fields, which store binary data such as images or documents.
The FIPS Q&A reinforced that enabling FIPS mode does not automatically make an entire application or environment compliant. Talha explained that organizations must also evaluate application code, password handling, the operating system, hardware and other relevant components as part of their compliance work.
Final Takeaway
The webinar demonstrated how DDM and FIPS support address different aspects of OpenEdge security. DDM controls which roles can view sensitive field values, while FIPS mode introduces cryptographic requirements that teams need to consider when preparing applications and migrating existing database users. Explore the OpenEdge Advanced Security package to learn more about the available capabilities and how they can support your organization’s security requirements.
For organizations evaluating these capabilities, the demonstrations provide a practical starting point for understanding configuration, activation and testing. Watch the full on-demand webinar to see both demonstrations and hear the complete Q&A directly from our OpenEdge experts.
Continue reading...