There are three local Windows service accounts that you will encounter on a very regular basis.  These accounts are intended to provide the appropriate amount of privilege necessary to services or applications running in their context.

They are:

1. Local Service
2. Network Service
3. Local System

Scan through the Service Manager in Windows and you will see these three accounts being used on most or all services.  This is typically the best practice, although there are cases where creating another account with more finely grained permissions may be suitable.

Privileges Granted

1. Local Service – Provides a low level of privilege on the local machine only, and is treated as an anonymous account on the network.
2. Network Service – Provides the same low level of privilege on the local machine, but is presented to network resources as the local machine.  This requires that Active Directory be configured to allow this machine account to function on the network.
3. Local System – Fully privileged local account that has complete control over the operating system and all resources.  It also has the same network rights as Network Service.

Least Privilege

All engineers must be acquainted with the concept of tuning permissions so that an application or service has only the rights it needs to execute; nothing more and nothing less.  This is a pretty basic concept.  However, we can take it to another level by thinking about a multi-tiered environment, particularly an environment with outward facing web servers.

Consider ASP.Net; it also runs in the context of some account, whether it is the logged in user or a default account (such as IUSR).  A web server (as a logical role, not necessarily a physical machine) should fundamentally be dedicated to interacting with a user.  This means collecting information and presenting information.  As a best practice, the web server’s security context should not allow writing to the file system, launching executables, connecting to sensitive systems, etc.  Connection to a database is often necessary (via a business tier) but this should be done with (once again) a Windows or database account that has the least amount of privilege required to do its job.

So how can we allow our web applications to be fully functional while still executing in the context of weak accounts? Quite simply; use private services to accomplish privileged tasks.

For example, suppose a web site needs to read accounting data from an internal system to present public year-end numbers.  Allowing the web server to communicate directly with the accounting server would be a terrible idea; the web server should be in a DMZ and the local accounts should not even have rights to access network resources.  That way, even if the entire server is compromised, the hacker controls a machine that can’t do anything other than serve web pages and request (but only request) data from inside the network.

In this theoretical scenario, the architecture would look something like this:

• Web Server – Not a domain member; sits in a DMZ with only a few ports open (minimizing potential attack footprint).
• Web Server makes a request to a service inside the network: “Can you send me those public year-end numbers?”
• Proxy Service – has privileges to access whatever it needs in the accounting system, but only responds to requests for data it is allowed to share.  If you compromise the web server, and make a request to the service for anything else, it will simply ignore you.  Better still, it could identify the rogue request and immediately deny all subsequent traffic until reset by an authorized administrator.
• Accounting System – only accessible to trusted local resources inside the network.

Now let’s add another dimension to the situation, one that is all too common.  The network perimeter may be properly secured, but what about internal access? Data loss often occurs due to malicious or inadvertent actions on the part of employees, not fabled hackers sitting on the other side of the globe.  The administrator that configures our Proxy Service in this example should only give the developers of the service the rights that they need to make the application function correctly.  If they grant too great a degree of access, the problem is manifold.

1. The developer may write code that doesn’t actually work when permissions are tightened.
2. Permissions may never be tightened; “Hey, it works, let’s not break anything.”
3. The developer is now responsible for the access he or she has been granted.  They may inadvertently compromise data, they may steal it, or they may simply be a logical suspect–because they had access.

Conclusion

Ultimately, it all comes down to three major principles:

1. Grant only the permissions an entity needs to perform its task.
2. Make sure that tasks are broken out into a components that can be placed behind appropriate security boundaries.
3. Lastly, don’t remove functionality in the name of security.  Find the correct ways to secure rich, interactive, insightful applications.