BeyondTrust

Security in Context: The BeyondTrust Blog

Welcome to Security in Context

Bringing you news and commentary on solutions and strategies for protecting critical IT infrastructure in the context of your business.

Keeping Your Flat File Databases Secure

Posted May 6, 2010    Morey Haber

Let’s move on to something less controversial (complete with new editor).

Just a few weeks ago Dark Reading featured an interesting article highlighting the risks and sensitivity of data in flat file database formats.

A lot of focus has been placed on database scanning, however users tend to ignore flat file databases used for applications and local data files that are produced as subsets. Very little information is present on best practices for securing flat file based databases and how to mitigate the risks of data contained within them.

It’s a valid argument to suggest that database application servers are not as secure as flat files. To some this may seem reasonable, as standard database solutions may have more visibility as an attack vector. And if you consider that any file contained on a host could be sensitive with regards to the information contained within, flat file databases are more secure because of local permissions and the operating system itself.

However, flat files are only as secure as the permissions, operating system, and application services that protect the files. Unlike widely adopted RDBMS solutions which provide built-in auditing, event notification, encryption and granular access controls, applications that utilize flat files may rely on the application developer(s) to provide these services.

When deploying any new application or reviewing existing ones, I’d like to propose a process for investigating the data storage capabilities of the application. The Microsoft operating system does a good job keeping MS Office documents, and MS Access database files in the My Documents directory. This makes it easy to secure by user.

But what about applications that store flat file databases in nonstandard locations? What if the application uses nonstandard file extensions to mitigate the association of the files? What if your web application needs a flat file database? What if the application managing the data provides another layer of granular access control to the data?

As a part of the security model when reviewing a new or existing application, consider the following:

- How does the application store data?

- What file format is the data stored in?

- Can the file system be secured with permissions to isolate the files?

- Does the local user need to be an administrator in order to access the files?

- Can the files contain a different permission set then the user login?

- Can you secure the services for the application with different permissions than the logged in user and the files?

- Are temporary files created containing flat file data and are they purged when the application is complete?

- Are the data files password-protected or encrypted?

- What is the location of the files and can they be moved to a standard location for backup, deletion, and security?

- Consider that even a text file and XML file can be considered flat file databases and are especially sensitive when used with web applications.

- What auditing facilities are available to track access and changes to the file data?

In doing my research, I saw that very little information is available about securing flat file databases. There are only a few guidelines available, but nothing appears to be fully comprehensive to solve the problem especially for end user guidance.

If your organization stores critical data that may be a violation of regulatory compliance initiatives, be mindful. You will need to find this data and secure it just like any other secure process within your organization. Also consider, if these files are not secure what liability you may have if they are exposed. An HR spreadsheet can be considered a sensitive flat file database depending on the data it contains too.

Leave a Reply

Additional articles

Integrating Least Privilege and Password Management to Solve Account Security Challenges

Integrating Least Privilege and Password Management to Solve Account Security Challenges

Posted July 24, 2014    Morey Haber

There is a reason all BeyondTrust Privileged Account Management (PAM) solutions share the PowerBroker name: They all inherently enable you to reduce user-based risk and can be integrated under a centralized IT risk management platform. Here’s one common use case that demonstrates how this integration changes the playing field. Consider the challenge of privileged access:…

Tags:
, , , , ,
PowerBroker Password Safe Password Age Report

Reshaping Privileged Password Management with Password Safe 5.2

Posted July 21, 2014    Martin Cannard

Today, we’re pleased to unveil the latest edition of our privileged password management solution, PowerBroker Password Safe. I’ll start with a brief intro of what’s new and then tell you a little about the driving factors behind Password Safe development. New features for mitigating password risk and ensuring accountability enterprise-wide Here’s the 10,000-foot overview of…

Tags:
, , ,
PowerBroker for Windows tamper protection

PowerBroker for Windows 6.6 Tamper Protection

Posted July 18, 2014    Morey Haber

I have a bone to pick: Stopping an administrator from performing an action on a system is futile endeavor. As an administrator, there is always a way to circumvent a solution’s from tampered protection. Really! By default, Windows administrators have unrestricted access to the system – and even though an application, hardened configuration, or group policy…

Tags:
, ,