Académique Documents
Professionnel Documents
Culture Documents
Fundamentals of
Effective File Server
Security
sponsored by
by Greg Shields
Article 1: Enforcing File and Folder Security ............................................................................................... 1
Share Permissions .......................................................................................................................................... 2
NTFS Permissions ........................................................................................................................................... 2
How to Set Permissions .................................................................................................................................... 3
Automating Permissioning .............................................................................................................................. 5
Net Share ............................................................................................................................................................ 5
Icacls.exe ............................................................................................................................................................. 5
PowerShell ......................................................................................................................................................... 6
Going Beyond Native Toolsets ....................................................................................................................... 6
Article 2: Enumerating File and Folder Security ........................................................................................ 7
Viewing Permissions .......................................................................................................................................... 7
Native File and Folder Enumeration Remains Painful ..................................................................... 10
Article 3: Auditing File and Folder Access .................................................................................................. 11
Auditing Considerations ................................................................................................................................ 11
Configuring Auditing ....................................................................................................................................... 12
Command‐Line Auditing ........................................................................................................................... 13
Mining the Security Event Log .................................................................................................................... 14
Centralized Auditing and Reporting via Third‐Party Tools ........................................................... 15
i
Copyright Statement
© 2009 Realtime Publishers. All rights reserved. This site contains materials that have
been created, developed, or commissioned by, and published with the permission of,
Realtime Publishers (the “Materials”) and this site and any such Materials are protected
by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of Realtime Publishers or its web site
sponsors. In no event shall Realtime Publishers or its web site sponsors be held liable for
technical or editorial errors or omissions contained in the Materials, including without
limitation, for any direct, indirect, incidental, special, exemplary or consequential
damages whatsoever resulting from the use of any information contained in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, non-
commercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
Realtime Publishers and the Realtime Publishers logo are registered in the US Patent &
Trademark Office. All other product or service names are the property of their respective
owners.
If you have any questions about these terms, or if you would like information about
licensing materials from Realtime Publishers, please contact us via e-mail at
info@realtimepublishers.com.
ii
[Editor's Note: This eBook was downloaded from Realtime Nexus—The Digital Library for
IT Professionals. All leading technology eBooks and guides from Realtime Publishers can be
found at http://nexus.realtimepublishers.com.]
Article 1: Enforcing File and Folder Security
Files and folders…folders and files…data everywhere! It seems like even the smallest of
business networks somehow aggregate mounds of those individual buggers each and every
day. Collecting up on our file servers, it is the protection of that data that is arguably our
primary job as IT administrators.
Yet as a fundamental part of our daily activities, managing file server security is one task
we must accomplish using some of the least‐capable tools in our administrative quiver.
With little more than an Explorer shell and a few native command‐line tools, we’re charged
with maintaining the security and availability of our business’ most critical assets: Its data.
Effectively managing file server security is a three‐fold responsibility: We must first ensure
that rights and permissions are set correctly to give the correct people access and keep the
wrong people out. Lacking specialized tools to assist, completing this task requires large
amounts of mouse‐work as we click through to set each file and folder’s properties.
But setting security isn’t efficient without a good visualization of the structures we have to
work within. The second responsibility in effective file server security is in enumerating
files, folders, and their assigned permissions. Lacking tools here, we’re further forced into
highly‐manual activities that don’t scale with the growth of our data.
The third facet of this responsibility arrives as an unfortunate side effect of how dynamic
an IT environment really is. Once set, we must constantly and comprehensively audit that
security to make sure it hasn’t been changed. Ultimately, keeping the wrong people out is as
much work as locking them out in the first place.
It is the goal of this Essentials Series to assist you with these three responsibilities. You
know as well as the next IT professional that enforcing, enumerating, and auditing file
server security can be a painful process without the right tools. This series will show you
tools that are available right within the Windows operating system (OS). Along the way,
you may discover that alternative solutions might come in handy for easing the strain of
this daily activity.
1
There is often some confusion as to what privileges are conveyed through each of these two
permission structures. Part of this confusion is because both NTFS and shared folders
leverage similar permission sets such as Full Control and Read. By design, NTFS
permissions control the access to a particular file or folder. That access holds true no
matter how the user navigates to the file or folder’s location. Share permissions, however,
apply only to objects that are accessed through a defined shared folder path.
Share Permissions
Share permissions are often considered the gatekeepers of a shared resource. Correctly
implemented, they limit the boundary of access that a user can have on any item within the
share. This extra security boundary enables a blanketed control over all file and folder
access within the share, which is then tailored down further using the NTFS permissions
applied to each individual file and folder. There are three levels of control exposed at the
share level:
• The most basic access is Read. Read allows a user to be controlled by the Read &
Execute, List Folder Contents, and Read NTFS permission groups.
• The next level of control at the share level is Change, which exposes all the
additional NTFS permission groups except Full Control.
• The final level, Full Control, allows access to the remaining NTFS permission group
of the same name.
It is important to remember share permissions do not grant any direct access to files or
folders. They only enable a configured user or group to traverse through the share. The
other half of permissioning is handled using NTFS permissions.
NTFS Permissions
Once through a shared folder, NTFS permissions further define which users can access
which resources. These permissions control access to the file or folder itself as well as to its
specific attributes. At their most basic level, NTFS permissions define whether a user or
group can read, write, and ultimately delete a particular file or folder.
But these three rights are only the most basic of those that can be assigned. An additional
set of “special permissions”—over a dozen in all and different based on each object’s
type—can be assigned as necessary. This granularity enables you to create complex
permissioning structures where users can traverse folder structures but not read their
contents or create files but not delete them. Exceptional care is necessary when working
with these special permissions, as their incorrect assignment can create havoc for user
access.
2
Complicating this situation even further, the permission structure for NTFS is cumulative. If
a user is a member of several groups that have all been granted different permissions to a
file or folder, the user will be granted the least‐restrictive effective permission. As such,
keeping a user out of a folder means not assigning its privileges to the user’s user account
as well as any of the groups to which the user is a member.
This cumulative behavior is also experienced with folder inheritance. With inheritance, a
file or folder can receive its permissions from the folder above it in the tree. Thus, down‐
level files and folders can have their permissions automatically assigned from another
folder that is one or many folders above in the file structure. Finding where those
permissions are assigned can be a challenging activity using native tools alone. In complex
environments with large folder structures, third‐party solutions are often necessary to
visualize and untangle what eventually becomes a spaghetti of inherited permissions.
Finally, the NTFS permission structure includes a powerful (and often painful) Deny
permission. Whereas access that is enabled through the standard Allow permissions
follows the rules previously mentioned, any Deny permission automatically and
immediately overrides everything. This is useful for creating a blanket restriction for
highly‐secure folders but must be used carefully. If you’ve ever accidentally set the Deny
permission for the Everyone group on a file or folder, you know how challenging this
permission can be to wield effectively.
How to Set Permissions
NTFS permissions are defined within Windows Explorer by navigating to the target file or
folder and viewing the Security tab of the object’s properties (see Figure 1). The Security
tab shows a list of accounts and groups that have access to the file. When a user or group is
selected, the permission groups enabled for them are highlighted.
3
Figure 1: Viewing NTFS permissions.
Clicking Edit will allow you to modify the permission groups assigned or associate new
groups. Clicking Advanced followed by the resulting Edit button enables access to edit
Advanced Security Settings (see Figure 2).
Figure 2: Editing advanced security settings.
4
This wizard allows you to associate users or groups with permissions on the targeted
object. It also allows you to control how inherited permissions affect the object and any
sub‐objects. Editing permissions from there allows access to the special permissions.
Yet these are all tools you already use today. You already use Windows Explorer to
accomplish at least the basics of permissioning through the GUI. What you need are
automation solutions that make this process easier. Let’s start by looking at some common
command‐line solutions that are available right out of the box.
Automating Permissioning
Windows Server 2008 ships with several command‐line tools to help manage NTFS and
share permissions. These tools help alleviate some of the scalability and consistency
limitations experienced with Windows Explorer. Three in particular are useful right out of
the box:
• Share permissions can be managed through the net share command.
• NTFS permissions can be managed with icacls.exe, also known as Improved Change
ACLs.
• Microsoft’s investment in Windows PowerShell further extends scripting support
through cmdlets such as Set‐ACL for working with NTFS permissions.
Net Share
Creating shares from the command line via “net share” is a fairly straightforward process.
To create the share, you must pass the share name and the path to the share:
Net share MyFolderShare=c:\Users\Administrator\Tools
Net share can also be used to grant permissions to users and groups when establishing the
share using the /grant switch:
Net share MyFolderShare=c:\Users\Administrator\Tools
/Grant:MyDomainSysAdmins@mydomain.local,CHANGE /Grant:steve@mydomain.local,FULL
As the previous example shows, the /Grant switch can be used more than once to add
multiple users or groups. Be aware that “net share” will not allow you to modify
permissions on an existing share.
Icacls.exe
Icacls.exe is a command‐line tool for managing both permissions and file integrity levels. It
is natively available in Windows Server 2008, Windows Vista, and Windows 7, and arrives
as an evolution of the cacls.exe command first available in Windows NT 4.0. Icacls.exe
offers rich permissioning support for files and folders, enabling an administrator to
automate the application of both simple as well as special permissions.
5
Its challenge is in its syntax. Although it is powerful in what it can do, applying permissions
using icacls.exe involves a complex aggregation of switches and inheritance operators. For
example, let’s assume you need to remove the existing inherited permissions from the
C:\Shared folder. At the same time, you want to directly apply the Read permission to the
Domain Users group and the Full Control permission for File Administrators. To
accomplish this, you would use the following icacls.exe syntax:
Icacls C:\Shared /inheritance:r /grant:r “Domain Users”:(OI)(CI)R /grant:r “File
Administrators”:(OI)(CI)F
Once through its learning curve, icacls.exe’s true power arrives by stringing together long
series’ of these commands to automate permissioning at multiple levels. Once scripted, you
can re‐run the script over and over again to reapply permissions to your file structure.
Note
A thorough explanation of scripting with icacls.exe can be found at
http://technet.microsoft.com/en‐
us/magazine/2009.07.geekofalltrades.aspx.
PowerShell
The final and arguably most powerful native tool is PowerShell, Microsoft’s new command‐
line automation framework. PowerShell provides a cmdlet called Set‐ACL that can be used
alone or incorporated within a larger script for managing NTFS permissions. Set‐ACL is
best used when modifying an existing permission set, whether that permission set is from
the object you want to modify or another object. The Set‐ACL solution is also the most
verbose of the command‐line options:
$AclToModify = Get‐ACL –Path ‘c:\Users\Administrator\Tools’
$NewPermission = New‐Object
System.Security.AccessControl.FileSystemAccessRule(“MyLocalDomain\Steve”,”Modify”,
”Allow”)
$ AclToModify.AddAccessRule($NewPermission)
Set‐ACL –Path ‘c:\Users\Administrator\Tools’ –ACLObject $AclToModify
Going Beyond Native Toolsets
As you can see, the native toolsets available in Microsoft Windows create a framework for
the enforcement of permissions. Yet each of these tools arrives with their own challenges,
requiring either heavy mouse‐work or a deep knowledge of scripting to be truly useful.
As the primary job of every IT administrator, managing data on file servers requires a lot of
time and effort. As such, other non‐native solutions may be necessary as the size of your
data scales. These tools enable the graphical visualization of permissions structures
through built‐in discovery, reporting, and analysis engines. With the right views in place,
administrators can leverage built‐in automation that defines and maintains widespread
permissions based on best practices. If the management of your file servers is a strain,
consider looking to external solutions for enforcing your file and folder security.
6
Article 2: Enumerating File and Folder
Security
Assigning permissions to files and folders is an important task. But you won’t get far
without first having a useful enumeration of your folder structures themselves. Windows
Server 2008 provides numerous tools to visualize the access permissions set on your files
and folders. Primary tools for this are the Windows Explorer GUI as well as command‐line
tools such as showacls.exe, icacls.exe, or PowerShell’s Get‐ACL. Unfortunately, these tools
are limited in flexibility for environment sizes that go much beyond the very small.
Effectively using them requires you to aggregate results from other solutions or turn to
third‐party solutions for a comprehensive analysis of file and folder security. With this in
mind, let’s take a look through the tools that are natively available, with an eye towards the
features and capabilities that one might want in an external solution.
Viewing Permissions
Viewing NTFS and Share permissions from Windows Explorer requires the individual
examination of each file or folder. Share permissions can be determined only by opening
the properties dialog box from of the root of the share (see Figure 1).
Figure 1: Viewing NTFS and Share permissions from Windows Explorer.
A similar process can be used to examine the NTFS permissions for a specific object via
Windows Explorer from the properties dialog box. Administrators can dig deeper into the
application of these permissions by going to the Advanced view, as shown in Figure 2.
7
Figure 2: Digging deeper into permissions application.
These wizard screens are excellent for the single‐instance application of permissions. Their
use works well when you need to apply only a few permissions to a few folders. Yet they
don’t scale. The process to set each new permission can require a minimum of seven mouse
clicks, with special permissions requiring an even greater number. More permissions
equals more mouse clicks, which reduces your effectiveness and increases the effort
required to do your job.
To combat this, Microsoft provides command‐line tools for working with NTFS and Share
permissions that include options for reporting. These command‐line reporting options
enable the creation of text output that can be redirected to a file for later viewing.
Using the net share command with no options will provide a listing of all shared folders on
a system, including the share name, path, and any assigned remarks. Specifying a share
name with net share will display share details, which adds information about the maximum
limit of users, caching settings, and assigned permissions. As an example, to report this
information about the MyFolderShare to a file called filepermissions.txt, use the following
syntax:
subinacl.exe /share MyFolderShare /display
/outputlog=”c:\securitylog\filepermissions.txt”
As subinacl.exe also can manage file system permission, shown below is a similar syntax
which reports on NTFS permissions for files:
subinacl.exe /subdirectories c:\Users\Administrator\Tools /display
/outputlog=”c:\securitylog\filepermissions.txt”
8
This command structure enables icacls.exe to report on a file’s NTFS permissions. However,
more useful is the ability to save that structure to a file for later reapplication. Consider the
situation where you’ve created a rich set of permissions for a large file structure. Using the
/save switch, as shown below, icacls.exe will create a text file that contains the folder and
permissions structure in Microsoft’s Security Descriptor Definition Language (SDDL)
format:
icacls c:\Users\Administrator\Tools\* /save ACLFile /T
Replacing the /save switch with /restore in the previous code snippet will restore the text
file’s saved permissions to your file structure. The net result is the ability to quickly restore
an entire structure’s permissions as necessary to fix a mistaken permission or simply
ensure that your permissions are set to your established standards.
Showacls.exe is another command‐line tool, found in the Windows 2003 Resource Kit,
which can be used for retrieving and viewing NTFS permissions. The differentiator with
showacls.exe is in its ability to report on the specific permissions assigned to a user or
group, similar to the Effective Permissions option found within Windows Explorer:
showacls /s c:\Users\Administrator\Tools\* > ACLFile.txt
showacls /s /u:MyDomain\administrator c:\Users\Administrator\Tools\* > ACLFile.txt
When possible, showacls.exe will use the simple permissions Read, Change, or Full Control.
If the permission structure is more complex, it provides an “access mask,” which attempts
to sum up the access rights. More information about configuring access masks can be found
in the tool’s help file.
Windows PowerShell’s Get‐ACL cmdlet accomplishes many of the same textual
visualizations seen in the previously mentioned tools but with the added power of
PowerShell’s rich scripting architecture. Get‐ACL returns a
System.Security.AccessControl.DirectorySecurity object for each file and directory it is run
against, which can be later repurposed for other uses within a larger PowerShell script
infrastructure. The Access property of this object contains the file or folder permissions:
Get‐ACL c:\Users\Administrator\Tools\*
As a full scripting language, PowerShell provides several display options over and above
the alternatives, including exporting to XML, comma separated value (CSV) files, or HTML.
9
Native File and Folder Enumeration Remains Painful
Each of these examples provides you with yet another view of your files and folders. But as
you can obviously see, their results are almost entirely text‐based. Although native tools
indeed enable you to enumerate and visualize your permissions structures, you can argue
that their text‐based nature isn’t much better than Windows Explorer alone.
Environments that need greater visibility into file server security must look to external
solutions. These solutions enable the discovery of file and folder structures as well as their
assigned permissions. Their aggregation of permissions information across multiple file
servers into a central and consistent format enables the reporting on permissions across an
entire infrastructure at once. Storing permissions centrally also enables administrators to
see how and where permissions structures have evolved over time, whether by server,
user, group, or combination therein. Leveraging this file server metadata with a well‐
formed API for accomplishing needed tasks ensures that the job is done right. Lacking a
substantial scripting investment, this capability is simply not possible using native toolsets
and homegrown solutions.
The needs of security are but one facet of file server management. A third‐party solution
becomes more valuable when the reporting is needed to meet regulatory compliance.
Regulations such as the Sarbanes‐Oxley Act (SOX), Health Insurance Portability and
Accountability Act (HIPAA), Gramm‐Leach‐Bliley Act (GLBA), Federal Desktop Core
Configuration (FDCC), and Payment Card Industry (PCI) require IT departments to
positively show that proper access controls are in place on critical data. As you’ll find out in
the third article of this series, third‐party solutions provide needed templates or reports
that are designed to meet the auditing requirements imposed by those regulations.
10
Article 3: Auditing File and Folder Access
The third rail of effective file server security is all about assurance. Assuring that the right
users have access to data preserves availability. Assuring that everyone else stays out
preserves security. Assuring that permissions on files and folders are always correctly set
preserves compliance.
Auditing access to Windows Server 2008 file servers is the primary mechanism through
which this assurance is achieved. Auditing enables administrators to verify that security
controls put in place are working properly, all the while logging access and modifications to
controlled files. Auditing can be enabled via the Windows Explorer GUI, command prompt
tools, and Group Policy. Like reporting on access controls, the auditing process is per server
and the logging of controlled events is done to the local event log.
A correctly‐developed auditing system provides a number of benefits to the organization. It
assists in securing the enterprise by determining inappropriate access to files or folders. It
provides for the maintenance of a modification history across data, applications, and
operating system (OS) configurations. And it creates the necessary documentation for
meeting regulatory standards.
Auditing Considerations
The first step in deciding to audit file server access is determining what type of events to
audit. For many IT organizations, the selection of auditing categories is often defined by
internal security organizations in cooperation with applicable rules of regulatory
compliance. Although each compliance regulation is uniquely different in its guidance, all
generally require that user and administrator actions are tracked into an auditable
database. For some, that database can be your Windows servers’ Event Logs.
The first step in this process is to designate a purpose to each audit rule. Auditing rules
have several typical purposes. They can assist in securing the enterprise by determining
inappropriate access to files or folders. Auditing also allows the maintenance of a
modification history outside of any application‐specific modification tracking.
This linkage between auditing rules and business goals is critically important, as there can
be unintended effects when purposes are not designated to an audit rule. The first of these
relates to collected events that do not further the organization’s goals. Collecting these
events consumes resources, leads to log maintenance issues, and makes event filtering
dramatically more difficult. Therefore, discretion is required when developing an audit
policy so that only the appropriate types of access tracking are monitored.
The second unintended effect stems from possible legal exposure. Your organization’s legal
counsel should review your auditing strategy. Their legally‐focused review helps to ensure
that the auditing purpose covers potential exposure and that the policy is defensible.
11
Note
In short, your audit policy should collect the minimum amount of auditing
information that is necessary to accomplish your business’ goals.
Windows Server 2008 provides for auditing on folders as well as individual files. File and
folder auditing can monitor access to both simple as well as special permissions as
discussed in the first article of this series. For each object, assigned auditing rules can
monitor for success and/or failure in exercising the users’ permissions.
As with permissions, it is important to remember that auditing configurations are also
inheritable. Thus, if extensive auditing is set up and allowed to pass down the settings to a
large number of files, a great number of audit entries could be generated.
Configuring Auditing
Auditing must first be globally enabled before setting auditing rules on individual files and
folders. Doing this across multiple machines in an environment is most commonly
accomplished via Group Policy. Navigate to Computer Configuration | Policies | Windows
Settings | Security Settings | Local Policies | Audit Policy, as shown in Figure 1. Here, edit
the Audit Object Access policy to allow the tracking of Success and/or Failure events.
Figure 1: Enabling auditing via Group Policy.
Once the global audit policy is enabled, configuring auditing on individual files and folders
can be performed using Group Policy, Windows Explorer, or command‐line tools. As with
the global policy, leveraging Group Policy for individual file and folder configuration
ensures a comprehensive approach. Right‐click Computer Configuration | Policies |
Windows Settings | Security Settings | File System, and select Add File to add a file or folder
to the policy (see Figure 2).
12
Figure 2: Configuring auditing of NTFS access.
After entering the file path, click Edit Security to bring forward the same Security wizard
you’re used to seeing when managing permissions directly in the file system. Click
Advanced, and select the Auditing tab of the Advanced Security Settings window to
configure audit settings using the GUI.
Command‐Line Auditing
Audit configuration from the command line is possible using the same Windows
PowerShell Get‐ACL cmdlet discussed earlier in this series. Get‐ACL is used to retrieve the
existing audit policy using PowerShell by supplying the ‐audit command‐line switch:
Get‐ACL c:\Users\Administrator\Tools\ ‐audit | Select‐Object –ExpandProperty Audit
To use PowerShell to create an audit rule, the Set‐ACL cmdlet is required:
$AclToModify = Get‐ACL –Path ‘c:\Users\Administrator\Tools’ –Audit
$NewAudit = New‐Object
System.Security.AccessControl.FileSystemAuditRule(“MyLocalDomain\gshields”,”ReadDa
ta”,”Success”)
$ AclToModify.AddAuditRule($NewAudit)
Set‐ACL –Path ‘c:\Users\Administrator\Tools’ –ACLObject $AclToModify
PowerShell provides a rich mechanism for scripting the creation of audit rules; however,
effectively using it requires familiarity with the .NET Framework classes that manage
access to the file system rules.
13
Mining the Security Event Log
After auditing has been configured, success or failure events will be stored in the Security
event log. Event log entries are stored per server, so be conscious of each server’s
maximum log size and how the event log is configured to react when the log size is reached.
Depending on the size of the log file and the number of events, there is a danger of losing
audit entries due to log size maximums being reached.
Note
Windows Server 2008 includes a feature called Event Log Forwarding, which
allows file servers to centralize event log data onto a single server. This
server can be configured to pull the event logs from the other servers or
those servers can pass selected events to the central server. More
information on Event Log Forwarding can be found at
http://technet.microsoft.com/en‐us/library/cc748890.aspx.
Gathering log information is only the first step. Effectively mining event log data for
meaningful events requires extra effort. With the release of Windows Server 2008, Event
Viewer provides several filtering options that limit the data being presented In Figure 3,
you can see how a few specific settings can greatly enhance the quality of information
viewed from the Security log:
• Logged. For a general‐purpose file system auditing log, this can be set at Any time.
• Event Level. All security audit entries will be Informational, so this filter is of
relatively little use.
• Event Logs. All the entries dealing with auditing are contained in the Security event
log.
• Event Sources. Microsoft Windows security auditing should be selected here.
• Task Category. Here, select the File System option.
• Keywords. The Keywords option is of little use, as all security audit entries contain
the keywords Audit Success or Audit Failure.
14
Figure 3: Event Viewer’s filtering options.
Once filtered, reporting from the Event Viewer is quite limited. A selection of events can be
saved to XML, text, or comma‐separated value files, but there is no facility for rich
reporting. Additionally, reporting efforts can be hampered by the limitations of event log
storage. In the most gracious scenario where all old event logs cannot be maintained in the
current view, the events are archived and those archives would need to be searched
individually in order to obtain information from them.
Centralized Auditing and Reporting via Third‐Party Tools
Auditing is all about assurance, but assuring effective auditing with native tools alone is a
challenge. As you can see, configuring auditing via Windows Explorer or Windows
PowerShell requires a number of steps and careful coordination to be effective. Each and
every file share must be managed as an individual item, which increases the chance for
errors or omissions in auditing. Although Group Policy assists this process, the natural
dynamics of an IT environment mean that Group Policies must be regularly verified to
ensure their policies remain correct over time.
15
IT environments with large numbers of file shares, large amounts of file storage, or high‐
security requirements may find that native solutions are insufficient for their needs. To
meet regulatory compliance and provide timely security information, you may find the
need to turn to third‐party toolsets. Their extended capabilities enable the central
configuration of an audit plan, central storage of audit data, customizable reporting,
alerting in the case of unauthorized access, and enhanced search features that are often
necessary as environments scale.
Download Additional eBooks from Realtime Nexus!
Realtime Nexus—The Digital Library provides world‐class expert resources that IT
professionals depend on to learn about the newest technologies. If you found this eBook to
be informative, we encourage you to download more of our industry‐leading technology
eBooks and video guides at Realtime Nexus. Please visit
http://nexus.realtimepublishers.com.
16