Unfortunately, organizations make this a one-time "security project" and never examine the settings again. 

Don't let your organization's data become inadvertently exposed by changes to your authority scheme.

More organizations are seeing the business requirement to secure critical data. Whether it's human resources information, payroll information, or credit card information, organizations are making the effort to set database access controls to appropriate settings—either "deny by default" (*PUBLIC *EXCLUDE) or "read only" (*PUBLIC *USE).

Unfortunately, organizations make this a one-time "security project" and never examine the settings again. Unless these settings are examined regularly, there's no assurance that the settings remain set to (or are in compliance with) your organization's security policy requirements. This leads to a rise in ""organizational risk" (the risk of loss resulting from inadequate or failed internal processes).

Consider these examples. An organization finds all of the files containing credit card information, sets them to *PUBLIC *EXCLUDE and uses adopted authority so that application users can continue to access the files containing the encrypted data. Another organization (a bank) secures its account information with authorization lists, setting them to *PUBLIC *EXCLUDE and only adding users who need access to the files from outside of the application (via ODBC, for example). In both cases, care is taken to authorize only the users who need access to the files. But also in both cases, no processes are put into place that require examination of these authorities. The results? In both cases, when I examined the authorities, users and groups had been authorized beyond the original list. Unfortunately (in both cases), no one knew when the new authorities were added, and no one reviewed the authorities for appropriateness.

How does this happen? I see two primary causes. One, a new application or process is added, and another process profile needs to be added to the list, usually without approval of the data owner or database architect and usually with *ALL authority even though something less, such as *USE, is sufficient. Two, a problem is being debugged. The *PUBLIC authority of the authorization list is set from *EXCLUDE to *ALL in attempt to resolve the problem. Because this rarely resolves the problem, the debugging effort moves to another part of the system and the altered authority is forgotten. Thus, data that used to be secure no longer is, and the vulnerable data remains that way until someone like me comes along and looks at the organization's security configuration.

More and more frequently, I see that data is unknowingly left vulnerable. Policy Minder makes it easy to check these authorities regularly. With Policy Minder, organizations need not wonder whether their data remains secured appropriately; they can be assured of it…painlessly.

How Policy Minder Helps

With Policy Minder, you can create a library template to define how objects are to be secured. You might want to define the security scheme for all application objects or for just selected files containing critical data. Once the template is created, you can run or schedule regular compliance checks. Using the exception report generated, you can easily identify whether changes have been made to the security scheme of any object. If no changes have been made, a one-page report is generated that states that everything is in compliance. You needn't look further or check anything manually. You know that the security scheme for these objects remains set correctly.

If you're using authorization lists, Policy Minder identifies any new users or groups added to or removed from a list. It also identifies whether any authorities have been changed. And just as with the library templates, a regularly scheduled compliance check will generate an exception report that will quickly show you what, if any, changes have been made.

Feel Secure

I admit to being rather passionate about making sure data is secured appropriately! That’s why I find it frustrating when an organization has taken the time to implement a more restrictive security scheme only to see it opened up because application objects and authorization list authorities aren't reviewed regularly.

Don't let your hard work be undermined. Don't let your organization's data become inadvertently exposed by changes to the authority scheme that open up a restrictive security policy. Don't raise your organization's operational risk by neglecting to regularly check these authority settings. Create a library, directory, or object template to maintain the appropriate settings on your critical application objects. Use the authorization list category to ensure that authorities have not been changed and that users or groups have not been added to the list without appropriate review and approval.

If you want more information on SkyView Policy Minder, a customized ROI analysis, or a 30-day free trial, contact us.