First, you should survey the various tasks necessary in each application, gather commonly performed tasks into as few job roles as possible, then assign those roles as necessary to user accounts. This will result in every user account and person being assigned only the permissions necessary to perform their allowed tasks.
Role-based access control (RBAC) should be applied to each computer, with every computer with the same role being held to the same security configuration. Without specialized software it's difficult to practice application-bound RBAC. Operating system and network RBAC-based tasks are easier to accomplish using existing OS tools, but even those can be made easier by using third-party RBAC admin tools.
In the future, all access control will be RBAC. That makes sense because RBAC is the embodiment of least privilege and zero admin. The most highly secure companies are already practicing it where they can.
Separate, separate, separate
Good security domain hygiene is another essential. A security domain is a (logical) separation in which one or more security credentials can access objects within the domain. Theoretically, the same security credential cannot be used to access two security domains without prior agreement or an access control change. A firewall, for example, is the simplest security domain. People on one side cannot easily get to the other side, except via protocols, ports, and so on determined by predefined rules. Most websites are security domains, as are most corporate networks, although they may, and should, contain multiple security domains.
Each security domain should have its own namespace, access control, permissions, privileges, roles, and so on, and these should work only in that namespace. Determining how many security domains you should have can be tricky. Here, the idea of least privilege should be your guide, but having every computer be its own security domain can be a management nightmare. The key is to ask yourself how much damage you can live with if access control falls, allowing an intruder to have total access over a given area. If you don't want to fall because of some other person's mistake, consider making your own security domain.
If communication between security domains is necessary (like forest trusts), give the least privilege access possible between domains. "Foreign" accounts should have little to no access to anything beyond the few applications, and role-based tasks within those applications, they need. Everything else in the security domain should be inaccessible.
Emphasize smart monitoring practices and timely response
The vast majority of hacking is actually captured on event logs that no one looks at until after the fact, if ever. The most secure companies monitor aggressively and pervasively for specific anomalies, setting up alerts and responding to them.
Sign up for CIO Asia eNewsletters.