Once robust security protections are in place and thoroughly audited, your organization should be well protected from external threats.
But are sensitive data like credit card numbers, social security numbers, and corporate financials truly protected within applications such as ERP and SCM software? Do employees with routine data reporting duties have access to private data? Regulations like GDPR and CCPA are proliferating and will only add to the growing pressure to secure sensitive data.
Keeping private data safe, particularly for legacy applications, often requires an additional layer of protection. We explain why in this blog, and how field-level security can help.
Keeping Sensitive Data Safe in Legacy Applications
At most IT organizations, security is taken more seriously than ever, and for good reason! New threats proliferate every year, best practices advance faster than ever before, and dedicated security resources are increasingly indispensable–even for highly secure platforms like Power i / IBM i.
In our experience, however, the intense focus on system-level security can lead some organizations to overlook the importance of securing sensitive data within those systems. While modern applications provide more robust data protection features, protecting sensitive data is a particularly important priority for legacy applications and ERP software.
For example, consider a legacy system that is secured using prototypical security capabilities such as user access control and virus protection. These defenses are vital, but they apply mainly to keep outside intruders from accessing the relevant system or application. For legacy applications, these outward-facing protections generally operate under the assumption that any user or group of users who has access to a given menu or screen can access all data fields on that screen. This can be problematic for various sensitive data (especially in the wake of new data privacy regulations like Europe’s GDPR law). Examples of sensitive data that can be more difficult to obscure in legacy systems include:
- Personal data like social security numbers
- Customer financial data like credit card numbers.
- Sensitive internal data like product pricing and cost information.
In short, most legacy applications were not designed with granular data protection in mind–at least at the level of individual fields. Legacy applications generally rely on security features built into the application itself. For example, certain users or groups of users will only have access to certain menus and/or screens. Within a given menu or interface, however, legacy applications have not historically provided functionality for obscuring sensitive information within specific fields.
Database-level protections in most legacy applications are similarly high-level: a given user either has access to the entirety of a given database file or none at all. In many legacy applications, attempting to restrict access at the database level can disturb complex permissions within the software itself, causing it to stop functioning. In effect, this means that protecting data becomes a major development effort, with extensive testing required for every integrated system. Modifying database-level permissions may necessitate development work and testing on dozens–or even hundreds–of integrated functions and systems. In many cases, rearchitecting an organization’s legacy applications to reflect contemporary best practices for data security is simply uneconomical.
Legacy applications and ERP software require an alternative. And that’s where field-level security comes into play.
How Field-Level Security Can Provide Protection at the Database Layer
In our experience, most organizations take the challenge of securing their systems extremely seriously. And the modern IBM i / Power i platform is a great place to build a rock-solid, highly secure foundation for business-critical applications. But it is important to recognize that it might be vital to extend your protection to the next layer, the database itself.
Field-level security capabilities provide a direct solution to the legacy application data-protection conundrum discussed above:
- Field-level security provides protection at the database level, which means specific fields can be obscured, even for users with access to the relevant software menu and/or database file.
- Because field-level protections return an anonymized value (i.e. “99999999”) when triggered, applications that call data from these fields do not need to be rearchitected whenever a new field needs to be obscured. Even external queries or integrations can be shielded from access to these fields.
- Field-level security effectively provides an additional, more granular layer of role-based data security that is amenable to fast, economical configuration changes.
Take Advantage of IBM i’s Built-in Field-Level Security Features for DB2
Since version 7.2, IBM i has offered DB2 field-level security capabilities called Row Column Access Control (RCAC). The feature provides the ability to secure data on a more granular basis, to the level of specific characters within specific rows and columns. Managed through SQL rules applied directly at the database layer, field-level protection is applied to queries from both integrated IBM i applications and external systems.
In its base implementation in IBM i, however, configuring RCAC functionality requires a database administrator, even for routine user access changes or rule modifications. The team at PSGi wanted to help, and we built a new Field Level Security Manager designed to simplify this process. Using this tool, it is far easier for non-technical users to quickly edit RCAC rules and permissions. We provide a detailed walkthrough of how it works in our blog here.
We understand that the process of securing data in legacy applications with hundreds of screens and integrations can be overwhelming. If you need help, we encourage you to reach out to our team. Our security audit process covers not only the best practices needed to secure your organization from external threats but a data protection audit informed by our decades of experience with legacy applications.
