Home arrow Security arrow Page 5 - Security Management Architecture

Administrative Security - Security

This chapter provides a thorough guide to many security issues. The authors encourage writing strong enforcement statements of acceptable use policies (AUPs) and provide examples of wordings and a best practices checklist. They cover how to limit authority and separate duties and how to pinpoint accountability. The chapter is from Network Security: The Complete Reference, by Mark Rhodes-Ousley, Roberta Bragg and Keith Strassberg; ISBN:0-072-22697-8, McGraw-Hill/Osborne, 2003.

  1. Security Management Architecture
  2. Examples of AUP Enforcement Wording
  3. Developing AUP Enforcement Policy Text
  4. Enforcement Processing
  5. Administrative Security
  6. Management Practices
  7. Activity Monitoring and Audit
  8. A System and Device Log File Example (Windows)
  9. System and Network Activity Monitoring
By: McGraw-Hill/Osborne
Rating: starstarstarstarstar / 5
May 11, 2004

print this article



When considering controls that determine the availability and integrity of computing systems, data, and networks, consider the potential opportunities an authorized administrator has as compared to the ordinary user. Systems administrators, operators who perform backup, database administrators, maintenance technicians, and even help desk support personnel, all have elevated privileges within your network. To ensure the security of your systems, you must also consider the controls that can prevent administrative abuse of privilege. Remember, strong controls over the day-to-day transactions and data uses of your organization cannot in themselves ensure integrity and availability. If the controls over the use of administrative authority are not strong as well, the other controls are weakened as well.

In addition to directly controlling administrative privilege, several management practices will help secure networks from abuse and insecure practices.

Preventing Administrative Abuse of Power

Two principles of security will help you avoid abuse of power: limiting authority and separation of duties.

Limiting Authority

You can limit authority by assigning each IT employee only the authority needed to do their job. Within the structure of your IT infrastructure are different systems, and each can be naturally segmented into different authority categories. Examples of such segmentation are network infrastructure, appliances, servers, desktops, and laptops.

Another way to distribute authority is between service administration and data administration. Service administration is that which controls the logical infrastructure of the network, such as domain controllers and other central administration servers. These administrators manage the specialized servers on which these controls run, segment users into groups, assign privileges, and so on. Data administrators, on the other hand, manage the file, database, web content, and other servers. Even within these structures, authority can be further broken down? -- that is, roles can be devised and privileges limited. Backup operators of file servers should not be the same individuals that have privileges to back up the database server. Database administrators may be restricted to certain servers, as may file and print server administrators.

In the large enterprises, these roles can be subdivided ad infinitum: some help desk operators may have the authority to reset accounts and passwords, while others are restricted to helping run applications. The idea, of course, is to recognize that all administrators with elevated privileges must be trusted, but some should be trusted more than others. The fewer the number of individuals that have all-inclusive or wide-ranging privileges, the fewer that can abuse those privileges.

Separation of Duties

Another control is separation of duties. In short, if a critical function can be broken into two or more parts, divide the duties among IT roles. If this is done, abuses of trust would require collaboration and, therefore, will be less likely to occur. The classic example of this separation is the following rule: developers develop software, and administrators install and manage it on systems. This means that developers do not have administrative privileges on production systems. If a developer were to develop malicious code, she would not have the ability to launch it, on her own, in the production network. She would have to coerce, trick, or be in collusion with an administrator. She might also attempt to hide the code in customized, in-house software; however other controls, including software review and the fact that others work on the software, mean that there is a good chance of discovery, or at least, perhaps, enough of a chance to deter many attempts.

Even on the administration side, many roles can be so split. Take, for example, the privilege of software backup. Should these individuals also have the right to restore software? In many organizations these roles are split. A backup operator cannot accidentally or maliciously restore old versions of data, thus damaging the integrity of databases and causing havoc. 

Remember: this chapter is from Network Security: The Complete Reference, by Mark Rhodes-Ousley, Roberta Bragg and Keith Strassberg (McGraw-Hill/Osborne, ISBN 0-072-22697-8, 2003).

Buy this book now

>>> More Security Articles          >>> More By McGraw-Hill/Osborne

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Secure Your Business for Data Privacy Day
- Google Testing Security Fob Password Alterna...
- Security News Highlights Concerns
- Going to Extremes for Data Security
- Skipfish Website Vulnerability Scanner
- Critical Microsoft Visual Studio Security Pa...
- US Faces Tech Security Expert Deficit
- LAN Reconnaissance
- An Epilogue to Cryptography
- A Sequel to Cryptography
- An Introduction to Cryptography
- Security Overview
- Network Security Assessment
- Firewalls
- What’s behind the curtain? Part II

Developer Shed Affiliates


Dev Shed Tutorial Topics: