Those of you reading this are likely working in industries with compliance mandates around protecting specific data types from misuse. And, like most businesses today, you’re probably using some kind of industry-specific set of applications that host that data – a health information management system in a healthcare setting, for example. So, your compliance focus – specifically those objectives around securing protected data – usually is directed at the application hosting that data, and not file servers on the network.
So, does a file server need to come under compliance?
You might think the answer really depends on whether protected data resides on a given server. But you couldn’t be more wrong. As you’ll see in a moment, if your organization works with protected data, it definitely exists on file servers.
There are three reasons why you need to consider including your file servers as part of your compliance efforts:
1. Applications Run on File Servers
Assuming you have an on-premise application hosting your protected data, that application runs on the same Windows server that also hosts file services. At the core of your industry-specific application is a database, right? And what is that database? A file, of course! So, if you’re truly concerned about the security and compliance of your protected data, you need to be auditing the access to, and usage of those files (with the specifics dependent on your compliance mandate).
If you’re not watching those databases at a file level, it’s possible (with some careful planning) for someone to make copies of the databases. And, suddenly, you’re not longer compliant!
2. Applications Utilize File Server
Some business models require the transmission of protected data. Credit card details come to mind, as does healthcare information being sent to process claims. That means data that was once safely housed in your industry-specific application, is now exported to a folder to be sent using some kind of file transfer application.
In theory, you should be using some kind of managed file transfer solution, but if you’re still using plain old FTP over an SSL connection, there is a period of time when your protected data is potentially exposed.
3. Users Put Data on File Servers
The moment a user saves a PDF report, performs an export of data, or writes correspondence in a Word doc that includes protected information, the server hosting any of these files is now subject to compliance.
In each of the three scenarios above, the onus is put upon IT to understand how protected data exists in their organization outside the application. The first two scenarios above are relatively easy – just identify where the databases and exported files are located, and put the necessary controls in place, such as file auditing, to monitor access to these data sets.
The third scenario is where it gets a bit tricky. Without some kind of DLP solution, or something that monitors file contents for protected data formats (e.g. a social security number format of ###-##-####), you’re never going to know. So, to certain you have compliance under control, you need a) a solution to tell you where your protected data is, and b) a file auditing solution to monitor access.
Including File Servers in Compliance
Because compliance mandates are written rather generically to allow every business to meet the standard’s objectives, most organizations have their own interpretation of what falls under the mandate, and how to demonstrate compliance. But, the fact remains, the file systems and applications that host your protected data must fall under compliance. The only conclusion that can be drawn is that at least some of your file servers will need to be subject to your compliance efforts.
To learn more about how file auditing helps meet compliance objectives, download the whitepaper The Role of File Auditing in Compliance.
This is a Security Bloggers Network syndicated blog post authored by Chris Bunn. Read the original post at: Enterprise Network Security Blog from ISDecisions