Abstract
Introduction
1. Securing Multi-tier Software System
2. Security Modeling Guidelines
2.1. Weakest Point Fortification
2.2. In-Depth Defense
2.3. Access Control
2.4. Compartmentalization
2.5. Privacy
2.6. Communication Confidentiality
2.7. Failsafe
Conclusion
Abstract discussing the security requirements to build a secure multi-tier software system. the discussion includes: 1. a preview of multi-tier models security features; 2. a description of security requirements through a compilation of some software security modeling guidelines based on readings from Building Secure Software: How to Avoid Security Problems the Right Way by Viega and McGraw (2002); these model plans need to be seriously considered for implementation while designing software systems, in order to prevent many common security pitfalls.
Introduction
Many multi-tier software models exist in the world today. From Microsoft Distributed Component Object Model (DCOM) to Web Services, passing by Sun’s Java Remote Method Invocation (RMI) and OMG’s Common Object Request Broker Architecture (CORBA), any model can be acceptable as long as the implementation is secure. This research will put forward basic, and essential, guidelines to follow in order to build secure software. The software security modeling guidelines are all based on the author comprehension of some security issues while reading from the excellent book by John Viega and Gary McGraw, titled, Building Secure Software: How to Avoid Security Problems the Right Way, published by Addison-Wesley in 2002. Basically, these modeling procedures enforce system security. In addition, each guideline can be implemented in more than one way, whereby, the software developer can follow one or a combination of two or more (or all) of the security guidelines, depending on the security requirements of the software system. By modeling the software following these guidelines, the software developer can avoid numerous common security problems. Certainly not to forget that there is also the choice of the programming language(s) to use to implement the software and the operating system(s) where the software will be running, which, both of them, do have a great influence on the strength of the security.
1. Securing Multi-tier Software System
Commonly used multi-tier models are DCOM, RMI, CORBA, and Web Services. The first three of those, namely, DCOM, RMI, and CORBA are equipped with their own default security features. For instance, DCOM, which exists only in the Windows’ COM-centric world, provides security through its authentication level. Basically, there are seven levels of security in DCOM providing varying degrees of authentication and data integrity. Sequentially from first to last, these are: No Authentication; Connect Authentication (client authenticated only on connection); Default Authentication (at the moment, not differentiable from Connect Authentication); Call-level Authentication (for every method call, to avoid hijacking attacks); Packet-level Authentication (for every packet of every method call); Packet Integrity-level Authentication (adds checksum to prevent tampering with data); and finally; Packet Privacy-level Authentication (fully encrypt all data). Java RMI provides, through its security manager, the ability to encrypt sockets and the ability to connect on Internet Inter-ORB Protocol (IIOP). When using this protocol RMI becomes known as RMI over IIOP. IIOP supports secure communication between client and server objects through the use of cryptography. In fact, IIOP was original designed by OMG as CORBA’s default communication infrastructure. CORBA, on the other hand, has quite elaborate security features. For example, CORBA objects can be configured to restrict method calls to clients with the required security credentials. Though web services do not have default security features, they can be secured using any of the security models provided in chapter 1. Below are some security modeling guidelines that can be followed while building software systems using DCOM, RMI, CORBA, Web Services or any other multi-tier architecture.
2. Security Modeling Guidelines
2.1. Weakest Point Fortification
The software is safe as much as its weakest point is safe. Envisioning that security is like a chain, it is true that a chain is as strong as its weakest point. Naturally, a hacker would find and concentrate the attack on the weakest access point of the chain. So it would be quite logical to fortify the weakest point in order to raise the security bar for the whole software. But the main question is how can one identify the weakest point in a system? Well, that would require some analysis of the whole system. Basically, in some systems it would be very easy to find the weakest point, while in others it might be more difficult. To give an example of what is a weak access point; consider a system that uses cryptography to encrypt sensitive data while sending it from point A to point B over a network. A hacker can eavesdrop the network and intercept the transmitted data between point A and B; so is the transmission medium of the network itself the weakest point of the chain? Of course not! That’s because the hacker will be intercepting encrypted data, and it would take a while to decrypt it. The hacker would certainly search for an easier way. In this case, the hacker might try to access the data before they get encrypted on the sending side of the network, i.e., before point A. Another way the hacker might try is to access the data after they get decrypted on the receiving side of the network, i.e., after point B. Assuming, for the sake of argument, that the sending side, before point A, is not well secured, then it would be considered an easier target for the hacker, and thus, the sending side is the weakest point in the security chain, and not the transmission medium of the network. Following the Weakest point fortification security model, the security measures before point A should be reconsidered and fortified.
2.2. In-Depth Defense
In-depth defense security procedure requires layering multiple layers of different types of defense mechanisms. This model anticipates the possibility of security breaches, and thus, advises of layering down multiple layers of defense. When one layer is breached, the attacker will be faced by another layer of different type. Notice the emphasis on the word different: the layers should be different from each other in principles of defense; otherwise, if the attacker can breach one layer, breaching an adjacent similar layer will be as easy. The idea here is to diversify the defense layers in order to make it extremely difficult for the attacker to figure out all of them at one go. As an example, consider a company that wants to protect data on its intranet. The company can throw a firewall. This is one layer of defense. Yet, to apply the in-depth defense security model, the company may need to also encrypt the data. This is a second layer of defense and of different type than the first. The hacker may trespass the firewall, but then, all what the attacker gets is encrypted data. But what if the attacker can decrypt the data? Well, a third layer of defense can be added, such as, a user authentication system, and so on… In fact, it depends on the sensitivity of the data and how much the company is willing to take security measures to protect its data.
2.3. Access Control
Access control security procedure states that a user access to a software system should be controlled with privileges and, possibly, with time limitation. Each user should be granted the least possible privileges required to perform the tasks that the user needs to do. In addition, and if possible, limit the user access to the system for the exact time that the user requires to perform the tasks. One example of a system that should but does not apply access control on one of its operations is the UNIX operating system. Though UNIX is considered a secure system, but it is not entirely flawless. Unfortunately, when an application requires using the SMTP (Simple Mail Transport Protocol) service, UNIX grants the application the root privileges! The reader should be aware that with the root account in UNIX, the user can do absolutely everything. So giving an application the root privileges does not constitute a good security policy, since the application might be controlled by a malicious user. The reason why UNIX does this thing is that, only the root user can open port 25 (required by the mail server). Giving the application the root privileges will allow it to open the port. How can the access control security model be applied in this scenario? The secure way, is to create an account in UNIX that has only the privilege to open port 25. The application will then login with this account. This is the least privileges principle. Another easier but not as secure way, can be the following: if the application was given the root privileges to open port 25, then the UNIX system should directly relinquish these privileges from the application as soon as it opens the port. This is the minimal time principle. What’s the most secure way then? The reader can easily figure it out! Of course, it is the combination of the least privileges and the minimum time principles.
2.4. Compartmentalization
The compartmentalization security procedure requires breaking up a system to multiple units (compartments) in order to minimize the damage effect on the whole system by isolating the damage to a limited area of the system. Such modeling is effectively used when building ships, whereby, the submersed part of the ship is divided into multiple separately sealed chambers. If, for some reason, the hull gets breached, it doesn’t mean that the water will flood the entire ship, and thus causing it to sink. Only, the chamber(s) in direct contact with the breach will get flooded, and the ship should be able to keep floating. Same reasoning applies while building web services. Since no one can guarantee that a system won’t eventually get cracked, yet, if that happens, should the entire system fall down prey to the attack? By using compartmentalization, the integrity of the software system as a whole, following a security breach, should hold in a reasonable way. The damage will be prevented from spreading to more than the localized area that was the access point of the attacker. An example of a system that uses this model is Solaris operating system. Operations in Solaris are broken down into a set of entities that provide specific functionalities to specific set of roles with restrictions. Breaking into the operating system does not mean that the hacker can do everything. For every function the attacker wishes to execute, the attacker needs to also break into the entity responsible of executing the specified function.
2.5. Privacy
The Privacy security procedure promotes the protection of personal information provided to the software system by its users. By enforcing data protection and by promoting to the users that the system protects their privacy, the users will then trust the system and consider it secure. Basically, even if the system is really secure in practical implementation, but if the users were not educated of the security measures of the system, then the system may not be considered as secure. So two things needs to be taken care in this security modeling: firstly, implementing security measures to protect privacy; secondly, promoting these security measures to the users, in order to establish the trust relationship between the users and the system. The first step in protecting personal information is by encrypting the sensitive data and by not leaving any information laying around in the system, since these might fall as an easy prey for an intruder. The second step is by enforcing constraints on the Database Management system (DBMS). There are several ways to protect the DBMS from unauthorized access. One way is by restricting access to the database to user groups which, in turn, are assigned specific access privileges. Another way is by using stored procedures, rather than giving users direct read and write access to the database.
2.6. Communication Confidentiality
Communication confidentiality procedure ensures, in addition to the secrecy, the integrity and the nonrepudiation of exchanged data with and within a software system. For secrecy, data communicated over a network should be unidentifiable when eavesdropped. For integrity, there should be a way to validate that the data is original, i.e., not tempered with. For nonrepudiation, the sender should be able to check that the intended recipient received the data, and vise versa, the recipient should be able to check that the data originated from the alleged sender (authentication process). These requirements of the confidential communication, namely secrecy, integrity and nonrepudiation, can be fairly handled with cryptography. Certainly, encrypting the exchanged data will make it, hopefully, useless for the eavesdropper. Even though that does not deter the attacker from altering the data, yet, cryptographic hashes provide a technique to validate its integrity by checking its checksums. To validate of the identities of the parties involved in the communication, digital signature, also a cryptographic technique, can be used. An example of a preexisting cryptographic protocol that is widely deployed is Secure Sockets Layer (SSL) or its recent successor, which is newer version of SSL, Transport Layer Security (TLS). SSL in itself provides two requirements of communication security, secrecy and integrity. To ensure nonrepudiation, SSL is usually combined with the digital certificate functionality provided by some Certificate Authority (CA). This type of security is described as security at the transport-level, which provides point-to-point (rather than end-to-end) security and document-wise (rather than element-wise) security. In case end-to-end and message-wise security are required, then, it is advisable to use what is known as message-level security. An example of message-level security protocol is WS-Security.
2.7. Failsafe
Failsafe security procedure requires devising failure modes in which a software system continues to operate securely and stably following failures. In many cases, attackers provoke a system into behaving insecurely by leading it into some sort of failure (or simply, they wait for it to fail in its own). This will provide them with an open window to launch a more successful attack. For the reason of the inevitable of failures, it is necessary that the web service, in case of failure occurrences, be able to continue operating stably and securely. This requires planning for alternative mode of operations, or failure modes. Certainly, this is not an easy thing to do! The developer has to foresee cases where the system might fail. Whether a software failure or a hardware failure, at the exact point in time when the failure occurs, the developer needs to devise a way where the system switches to the failure mode responsible of dealing with that specific failure. For instance, one type of Failsafe security model implementation is a model that involves hardware. This might be the replacement of one big server by two or more smaller servers (clustering). When some failure is detected in one server, that server is shutdown to prevent it from behaving insecurely, and at the same time another server, in the cluster, replaces it. One might argue that a smaller server may not be able to carry the same load of the bigger server which it replaces. Well, there is a way around that problem, and that is by load-balancing on multiple servers. The big server can be replaced by three smaller servers, whereby, two of them balance the load, between each other, of the replaced big server, and one stands for backup. When a failure (again hardware or software) occurs in one of the two servers, the backup server takes its place. Depending on the degree of the security required, the number of the server in the cluster can be increased. Another type of Failsafe security model implementation is a model that involves software. This might be by implementation of a Transaction service, whereby, in the case of an attack in a mid-step in an atomic multi-step functionality, the system should be able to roll-back to its original state. For example, in the case of transferring money from one bank account to another, where at least two steps are required, namely debit the first account then credit the second account, the system should perform these two steps atomically, i.e., as a single step, by applying a Transaction service. The Transaction will be able to roll-back the first account to its original state after the occurrence of a failure, probably due an attack, in-between the debit and the credit step. So, as it is clear in this example, it is not enough to continue operating securely after some failure, the system needs also to continue operating stably, and that by enabling it to re-instate its stable state before a transactional operation that fails.
Conclusion
This chapter introduced common multi-tier models and some generic security guidelines (seven of them) that can be applied, individually or in combination, on, supposedly, any software system. No doubt, that these modeling guidelines, when applied, will provide a reasonable protection for the software system. Though they were presented in a more theoretical than practical way, yet, finding the correct way to implement them is not difficult. Most importantly, they do not contradict each other. This provides the software developer with the option to apply all of them, simultaneously, on a single software system, in order to enhance the effectiveness of its security.
