Problem solve Get help with specific problems with your technologies, process and projects.

Separation of duties

A look at the simplest way to secure your Web server.

The phrase "separation of duties" is most often associated to the business practice of separating job functions among various individuals. Among other benefits, this can help prevent malicious actions from occurring and help catch those that do occur. The same theory can apply to information systems and servers. In the case of a Web server and e-commerce infrastructure, separation of duties can be critical to the integrity and protection of information.

A Web server is simply a computer that is set up with a process that will receive requests for Web content, and provide that content to the requestor. Integrated into that system can be software or additional processes to perform authentication, authorization and transaction processing.

Let us begin by considering authentication. When a user browses to a Web page and wants to identify him or herself, he must type in a username and password. The service or process that will store the list of usernames and passwords and tell the Web service whether the user's credentials are correct should be very well protected. As we've seen in the past few years, there have been a fair number of attacks on Web services (like Microsoft IIS and Apache). If a Web service is attacked and compromised, and the authentication service is on the same server as the process that provides Web content, then the list of usernames and passwords could easily be stolen. If the authentication service is running on a separate server (not running a Web service), then an attacker would have to mount a second attack for a separate type of service. This adds additional requirements to the attack, which is likely to make it much more difficult to execute successfully.

Authorization controls will ensure that authenticated users can only access the information that is associated to their profiles or accounts. Authorization data will usually be stored in the same location as the resources that are going to be accessed. In the case of most Web services, the process that runs the service will have an account on the server. The default for this account is often the root, administrative, or system user account. In the case where an attack is successful against a Web service, if it is running as a privileged user, then the attacker (operating as the Web process) might be able to do a significant amount of damage to the system. If separation of duties is implemented properly, the Web service could run as a non-privileged user. In that case, should the service be attacked and compromised, the attacker will be able to do very little outside of the normal functions of the service. This means that the attacker could change Web pages (deface the site), but would have a much harder time making critical changes to the system, or manipulating authentication or authorization information outside the domain of the Web service.

Transaction processing systems are a requirement for electronic commerce. A user must be able to submit personal data such as billing or financial information; the server must be able to store and perform operations securely using this information. If separation of duties is enforced, the database where this information is stored should be on a separate system from the Web service. As in the situation of authentication information, this information should be very well protected. If customer data is located on the same system as the Web service, a compromise of one service can lead to a compromise of others.

The disadvantage of separating processes between servers is the additional cost associated with more hardware and increased time spent by system or network administrators on multiple systems. Any situation where there is more than one publicly available service running on a server should be very carefully evaluated, as separating the processes can increase the overall security of the implementation, but can add a lot of additional overhead.

About the author
Jeffrey Posluns is the founder of SecuritySage, a leading-edge information security and privacy consulting firm. Prior to SecuritySage, Jeffrey founded and co-founded several e-commerce and security initiatives, where he served as President and/or Chief Technology Officer. He is looked to as an authority to speak on information security and privacy related issues and trends at conferences, in law enforcement forums, and in the media. He is a regular speaker at industry conferences organised by such groups as the Information Systems Audit and Control Association (ISACA), and the Association of Certified Fraud Examiners (ACFE). Jeffrey is also a trainer for the Certified Information Systems Security Professional (CISSP) certification course.

This was last published in November 2002

Dig Deeper on Information security policies, procedures and guidelines