Dr. Dobb's Journal November 2000
Most analysis of system vulnerabilities require that analysts create a security-specific model of the application, which is quite distinct from the functional model of the system that analysts would already have handy. An example of this is the technique described by Bruce Schneier in "Attack Trees" (DDJ, December 1999). Largely because of this, practitioners resort to adding security from the outside, such as with firewalls and PKI. This normally takes care of threats posed by outsiders, but leaves room for insiders to compromise the system. In a product development scenario, the problem is compounded because the undocumented security features of a previous release can get inadvertently designed out in the next release. Distributed applications add another level of complexity to security analysis. All these instances point to the need to include security as one of the concerns in the functional analysis and design of the software itself.
I was faced with exactly this problem when developing a financial product. In the search for a solution, I put together a security analysis and design/modeling technique that closely couples the security and functional model of the product. While the model is based on my experience with financial software, it is sufficiently generic to be suitable for other business applications as well.
The method broadly involves the following steps:
1. Determine the scope of the problem; that is, the product and its environment.
2. Partition this into zones having similar security concerns.
3. Analyze each zone for vulnerabilities in a structured way by focusing on the different stages in the access and use of objects in the zone.
4. Design countermeasures for each vulnerability and choose one or more of them based on their coverage and cost.
I call this model the "Onion Peel Model," with the security zones forming the "peels." Vulnerability analysis is done from the outside peel to the inside, as well as from the inside to the outside. At the risk of sounding similar to "Onion Routing," I have retained this name because it aptly describes the exposure of product zones from the inside versus outside.
Modeling starts with defining high-level security requirements (or the security policy) and a preliminary functional model. You can use existing guidelines for defining the security policy. For the functional model, any of the existing methodologies -- object-oriented analysis and design (OOAD) or structured system analysis and design (SSAD) -- can be used.
As in SSAD, the model begins with a context diagram depicting the system and its environment. The difference here is that I include the known physical components of the environment in the model, instead of considering only the logical ones as is done in a functional model. These components could include software components such as web servers, application servers, databases, and the like; and hardware components such as network cabling, satellite uplinks, and so on. The product and these identified components define the system that needs to be analyzed (the onion), and the diagram is called the "Onion Diagram."
The caveat when defining the onion is that the components that are not under your control (directly or indirectly) are not included inside the onion, but rather remain outside it. For example, it may be possible to utilize the security features provided by the database. In that case it is included in the onion. On the other hand, it may not be possible to assume attributes of commercially available off-the-shelf products. These then form the environment of the onion.
The onion is now partitioned into peels based on the similarity in the nature and criticality of the security concerns of the components. This ensures that you focus on similar and/or related security concerns during the analysis. Of course, the interactions of objects between peels should be minimized, and those within the peel should be maximized, but cohesiveness of security concerns takes first priority. The peels are documented in the Peel Diagram.
To illustrate, I define an Internet User Interface Peel consisting of the web interface of the application, where the concerns are that of controlling access, restricting sensitive data modification (like product prices), and so on. The network components, on the other hand, are placed in the Internet Communications Peel -- the issues here being network failure, intrusion, confidentiality, and the like.
To illustrate further, an e-commerce web site may need to secure its interaction with the payment system much more than its interface with the online customer. In that case, you should divide the mentioned Internet User Interface Peel into the Customer Interface Peel and the Payment System Interface Peel.
For a typical financial product, you can expect the following peels: Internet/Extranet User Interface, Internet/Extranet Communication, External Interfaces, External Interfaces Communication, Intranet User Interface, Intranet Communication, Product Services, Product Resources (this includes the physical elements of the product, such as scripts, executables, and so on), and Database and System Resources; see Figure 1. The functional model is distributed over the User Interface peels and the Product Services Peel, the latter containing most of the business functions.
If the product services are distributed over several physical machines, the corresponding Communication Peel (Internet or Intranet) includes all the network components and services, the Product Services Peel will include all the distributed services; similarly, the Product Resources Peel and the System Resources Peel will include all the distributed machines.
In the beginning, you may not know much about the physical environment of the product. Details will start pouring in as the design proceeds. All that information needs to be fed back into the model and analyzed at checkpoints that you can define suitably. Also, as new modules are added/removed from the product, you can add/remove peels (or object sets, which are described in the next paragraph) from the model, thus taking care of maintenance and scalability.
Each peel is now further decomposed into object sets consisting of objects, again with similar security concerns and/or requiring similar levels of security. In the context of security, an object is defined as any logical or physical entity that contains information and can, therefore, be attacked (see "Role Based Access Control Models," by R. Sandhu, E.J. Coyne, H.L. Feinstein, and C. Youman, IEEE Computer, February 1996). I have extended that definition to include services, as they can also be compromised or shut down. The counterpart of the object is the subject: the entity trying to gain access to the object or change its state.
You may specify several levels of object sets for the purpose of abstraction, or more importantly, consider combined controls running across lower level object sets. As a rule of thumb, similar object types will comprise one object set. To illustrate, the External Interfaces Peel could consist of the object sets Online Messages and File Transfer; see Figure 2. Since the objects are heterogeneous in nature, their security concerns are different (for example, alternative network routes for the former, and alternative file transfer mechanisms for the latter). However, similar security concerns will always take precedence over similar object types. For example, an authentication server along with its database, key management services, and so on, in the Internet Communication Peel will form a single object set since all its components are involved in providing a single service -- authentication. (Here a control, the authentication server, is defined as an object set. This is how the model will be recursively applied to ensure the security of the controls themselves.)
Now comes the difficult part -- exposing the vulnerabilities in the onion, the peels, and the object sets. It seems most logical to go about looking for vulnerabilities the way the attacker would (be a thief to catch a thief). Taking this approach, I have defined five Levels of Penetration (LOPs), which denote the different levels at which an attacker could gain control of an object. Another way of conceptualizing the LOPs is that they denote the different stages in the life cycle of an object from its birth to its death. Again, from the perspective of security, this seems to be the logical way of searching for concerns.
The LOPs, in increasing order of penetration, are as follows (note that I use the term "object" to denote the victim for the sake of simplicity. Depending on the level at which you are analyzing the model, the object would be the onion, a peel, or an object set):
Using the aforementioned LOP technique, you can systematically analyze the onion, its peels, and the object sets one by one, and design countermeasures for the exposures you discover. Common or shared controls are likely from a higher level to a lower one; thus, an access control provided at the peel level may be sufficient for all the object sets under the peel. In that case, you just cross-reference the control from the peel in all the lower level object sets. For example, a firewall in the Internet Communication Peel may permit less stringent access control mechanisms in the back-end system. However, if you find that the controls run across peels or peer object sets, you probably need to review the peel or object set definition. Combining two peels and then splitting them into two object sets, or introducing a higher level object set will typically resolve the problem. If you run across a situation where it is absolutely impossible to do this, the model lets you cross-reference the two (see Figure 2 for an example of cross-referencing across LOPs).
Also, take into account the constraints imposed by external interfaces on your product and those that you want to impose on the others. These are documented in the LOP analysis as in Figure 2.
As a final step, go over the completed model once more to combine, separate, or remove security controls across LOPs, object sets, and peels. Take their coverage and cost into account.
We applied this model to our financial product and discovered the following vulnerabilities.
Case 1: Failure Handling. Files containing financial transactions on remote centers are generated at the end of every day and sent to the concerned center. These files are encrypted for the purpose of confidentiality. When the operation was modeled in the Product Services Peel and the Exit LOP was analyzed, it was discovered that under a system failure condition, the download process could fail before the file was encrypted. Even though the downloaded file was created in a secure area, this flaw was considered serious enough to necessitate other countermeasures; that is, file deletion under trappable failure conditions. The fact that some failure conditions may still not be trapped meant that I had to introduce another control: When the operation was restarted (IA LOP), the previous run's temporary files were deleted.
Case 2: Access Control. In the old system, it was possible for any user to access the (UNIX) OS prompt and run an executable. This was discovered while analyzing the IA LOP in the Product Resources Peel. Consequently, access to the OS prompt was restricted to specified trusted users only.
The Onion Peel Model provides a way of modeling security by extending the functional model of the system, instead of divorcing one from the other. It provides another way of discovering vulnerabilities in the system by following the path of the attacker from the birth to the death of the victim. The model is capable of handling distributed applications and provides maintainability and scalability.
DDJ