Policy

When we talk about "Policy" in FESF, we mean exactly two things:

•      Whether data written to a newly created file should be transparently encrypted before being stored on disk.  Transparent encryption also implies storing Client-defined control information and FESF metadata information within the file.

•      Whether the data read from an existing FESF encrypted file should be decrypted before being returned to the application that's reading it and whether data written by that application should be encrypted before it's stored in that existing FESF encrypted file on disk.

Policy decisions are made in user-mode by the Client Solution. The Client's Solution code is called to make a Policy decision whenever (a) a new file is created (and before any data is written to it), or (b) an existing FESF encrypted file is opened (and before any data has been read from or written to it).  Although there are a few additional events that will result in FESF calling the Client Solution, these are the only times when FESF calls the Client Solution to ask for a Policy decision.

The Client Solution will use data provided by FESF and optionally other data it collects or maintains independent of FESF as the basis for its policy decision.  When a Policy decision is required, FESF provides the following information to the Solution:

•      The fully qualified path of the file being created or accessed. Specifically:

Ø For files on local volumes, this includes the Volume GUID identifying the volume on which the file resides, plus the directory path and file name.  The Volume GUID unambiguously identifies the volume and can be converted to a drive letter by an FESF-supplied utility function.

Ø For files on shadow volumes, the Volume GUID is predefined as being FE_SHADOW_VOLUME_GUID. The device name of the shadow volume is supplied as well as the volume relative path to the file.

Ø For files on the network, the Volume GUID is predefined as being FE_NETWORK_GUID. The server and share are supplied along with the share relative path to the file.

•      The Thread ID (TID) of the thread that is creating or accessing the file.  Given this TID, the Solution can determine the fully qualified path of the executing image and the Security ID (SID) under which the application is executing.  The SID identifies a user (including username and domain) or other Windows security principal (such as a security group). FESF provides utility functions to allow the Solutions to easily determine these values from the provided TID.

•      The file access (read data, write data, and others) that was granted to the accessing application.

•      The disposition of the file being accessed.  This indicates whether the file is being created, overwritten, appended, or just opened.

Thus, when a new file is created or an existing encrypted file is accessed, the Client Solution determines policy for that file based on some combination of:

•      Drive (or server and share), directory path, and name of the file being accessed

•      Path and name of the accessing application

•      Security context (that is, nominally the user) under which the application is running.

•      The action being performed on the file.

•      The access granted to the application for this specific open instance of the file.

Which of these variables are taken into account, and how they may be used to define Policy, is entirely up to the Client Solution.  In addition, variables other than those provided directly by FESF – such as the system on which the application is running, or the day of the week – could also be used.

By way of example, a very simple policy implemented by a Client's Policy DLL might be:

"We want any files that are created in the directory \MySecretStuff\ on the volume that is the C drive on this workstation to be encrypted."

That's pretty straight forward.  Or, a slightly more involved example:

"Decrypt all encrypted files on the network with the path \\SpecialForces\missions\ImpossibleMission\ only when they are accessed by a user that's in the Active Directory security group SecretAgents and from a system that is actively joined to a domain named MI5 or MI6."

That's also pretty simple but requires the Solution to get the name of the domain to which the machine is joined outside the mechanisms provided by FESF (it's easy: You just call the Windows function LsaQueryInformationPolicy).  A slightly more complex policy that a Solution could implement would be:

"We want all existing encrypted files accessed by Microsoft Outlook, regardless of the directory that the file may be in, to not be decrypted when Outlook accesses it, unless the file has the file suffix OST or PST."

This third example policy would ensure that if a user attached an encrypted document to an Outlook email, the encrypted version of the file would be sent, while still allowing locally stored Outlook data files (the OST and PST files) to be encrypted.