Access to security audit files on Windows7

When a folder is set up for sharing, you can have the system record access to the shared file through the operating system's access auditing feature. This feature can be implemented in the previous operating system version of Windows7. Security audits at this time are at the shared level. The entry point of a file server when sharing to allow users to access specific directories on the file server. Note that security audits at the shared level do not audit file access, which is file-level security audit access. That is, it is now only necessary to set up audit file access for a single file, which cannot be implemented in older file systems such as FAT32, and they can only set up access audits for the entire file and not for specific files.

Do you set up security audits at the file level or at the shared level?

Shared-level security can only set security audits on folders, so the flexibility is relatively close. File-level security audits allow you to set up audits on specific servers, directories, or files. Therefore, the system administrator flexibility is relatively high, can be based on the time required, in the appropriate place to deploy security audits. An audit of NTFS partitions allows you to tell your system administrator who is accessing or attempting to access a specific directory. In Windows network, the audit of access to some key network resources is a more general method to improve the security of network security and enterprise data, and security audits can be used to determine whether anyone is trying to access restricted information.

At what level is it advantageous to set up security audits? This mainly depends on the user's needs. As in a folder, there are hundreds of files. In fact, the more confidential may be six documents. At this point, if a secure access audit is implemented at the folder level, there will be a lot of audit records in the security log. It would be inconvenient to look at it at this point, and sometimes a useful record would be obscured by those useless records. For this reason, if there are more files or subfolders in one folder, and there are fewer files with auditing requirements, it is obvious that it is appropriate to set up audit file access at the file level (that is, for a few files). This can reduce the amount of subsequent maintenance by the system administrator. In contrast, in a shared file, there is a particular folder that is dedicated to placing confidential files, and it is more reasonable to implement security audits at the folder level. Visible at which level to achieve security audit strategy, and there is no fixed standard. This mainly depends on the user needs to set. If you have to say a specific reference standard, then you can choose from the following criteria, that is, at which level the audit records generated at least and can cover the user's security requirements, at which level to set up security access audits. To put it simply, it satisfies two conditions at the same time. The first is to produce the least audit records, easy to read, and the second is to meet the needs of user security. Often the two conditions are contradictory, and the system administrator needs to strike a balance between them.

Second, what kind of security audit strategy should be chosen?

In the audit file access policy, you can select a variety of security audit policies as needed, which tells the operating system what to do when the information is logged in to the security log, including the person, the visitor's computer, the access time, what has been done, and so on. If all the access operations are recorded in the log, then the volume of the log will become very large, but not easy to post maintenance and management. For this reason, system administrators often need to select specific events to reduce the capacity of secure access logs when setting audit file access policies. In order to achieve this goal, some of the following recommendations to the system administrator can refer to.

The first is the minimum access operation principle. In Windows7, this access operation is divided into fine, such as modifying permissions, changing the owner, and so on more than 10 kinds of access operations. Although it takes a while for a system administrator to consider which actions to choose or to make relevant settings, it is still a boon for system administrators. A subdivision of a privilege means that an administrator chooses a specific access operation to obtain a minimal audit record. Simply put, "the resulting audit records are minimal and can cover the security needs of users" is easier to achieve. Because in the actual work, often only need to audit specific operations. If only the user changes the contents of the file or access to the file, such as a small number of operations audit can be. Without the need to audit all operations. The resulting audit record will be much less, and the user's security needs can be achieved.

The second is the failure Operation priority choice. For any operation, the system is divided into two cases of success and failure. In most cases, in order to collect information that the user illegally accesses, it is only necessary to have the system recorded as a failed event. such as a user, who can only access a shared file read-only. The administrator can now set a secure access policy for this file. This information is recorded when the user tries to change the file. Other actions, such as normal access, do not record the relevant information. This can also significantly reduce the security audit record. Therefore, I suggest that, in general, you can only enable failure events. Consider enabling the Success event record at the same time if it is not able to meet the requirements. At this point, some legitimate users of legitimate access to the file information will also be recorded, at this point, it should be noted that the security log content may increase exponentially. In the Windows7 operating system, you can filter the contents of the log by brushing, such as "failure events", so that the system can only list those failed records, to reduce the amount of reading by the system administrator.

Third, how to use the honey strategy to collect information about illegal visitors?

In practice, system administrators can also use a number of "honey policies" to collect information about illegal visitors. What is called the honey strategy? It's really about putting some honey on the internet, attracting bees that want to steal honey, and documenting their messages. If you can set up some files that appear to be more important on a shared file on your network. The audit access policy is then set on these files. In this way, you can successfully collect those who are hostile to the illegal invaders. But this disciplined message is often not available as evidence. But only as a measure of access. That is, the system administrator can use this method to determine whether there are some "restless elements" in the enterprise network, always try to access some unauthorized files, or some files for ultra vires operation, such as malicious change or delete files and so on. To be able to buy the invincible. Once this information has been collected, the system administrator can take the appropriate action. such as strengthening the user's monitoring, or check whether this user's host has become someone else's broiler and so on. In short, the system administrator can use this mechanism to successfully identify internal or external illegal visitors to prevent them from making more serious damage.

Note: File substitution does not affect the existing audit access policy.

As pictured above, there is a picture file called capture, which I set up for file-level security audit access without setting any security audit access policies on its folder, "New folder." At this point, if the author of the same file (the same file name and no security audit access policy settings) copied to this folder, the original file cover. Note that this does not set any security audit access policies at this time. After the file is copied, the original file will be overwritten by the same name. However, this security audit access strategy is then transferred to the new copy of the previous file. In other words, the new file now has security audit access to the file that was previously overwritten. This is a very strange phenomenon, the author is also inadvertently found. I wonder if this is a flaw in the WINDOWS7 operating system, or is it deliberately set? This is to be explained by the developers of Microsoft's operating system.