jump to navigation

Keep it Secure Simple September 15, 2013

Posted by Jiaqi Wu in Security.

Security by nature is a challenging subject to understand.  As a result, implementing it in a solution is challenging as well. The decision of where to implement the majority of security will determine much of the secureness of the solution. This is due to several reasons. Implementing security in a solution requires a specialized expertise. Very few solution developers specialize in security due to its esoteric nature. Just as every type of developer, whether they are backend developers, UI developers, database experts, security experts are another type of valuable specialized resource on a solution team. This week’s article The Protection of Information in Computer Systems describes many different concepts of system security. However I wanted to expand upon this to the domain of how to make implementations of security simple for the solution developer.

Through my experience in platform development, security has always been a difficult issue to solve. How do you abstract security so that any developer can implement it in a solution while still having the security system be generic enough to fit all solutions? Lets use the subject of authorization as an example. The article for this week mentions Controlled Sharing which is a system that defines roles level access for access to a file or system. For example, for each file in the system, a user must be defined as allowed to read/write/execute that file [1]. Modern operating systems such as Linux implement this very well for the end user. An administrator in Linux is able to change the permission on the filesystem for different users with simple commands. However the mechanism for which the system actually determines when a user attempts to exercise the permissions is hidden. This is very simple to learn and to use. It is deemed a good abstraction in my opinion.

However security abstractions are not always made so simple. In fact, security simplicity is a matter in which I have a lot of personal feelings about while testing security services. There are two perspectives to this: the security expert and the solution developer. From the perspective of the security expert, the goal is to create a generic platform in which a solution developer can use to implement a solution. However, the security expert knows of all of the components of the system. Lets take authorization of web services as an example. What does a typical topology and implementation of security look like here? Well there needs to be an identity server to store users and to define role based policies, certificates for encryption, hook points to intercept web services calls. Lets not go any deeper than this. Perhaps from a security expert’s perspective, each of these components are simple and obviously necessary. So to implement a security service which abstracts these concepts, an example might result in abstraction layers to connect to an identity server and an API for the hook points in which a solutions developer might have to implement their own rules to determine user authentication. The security expert decides that each of these components should be left exposed to the solutions developer because he might figure that customizability might be useful for some. However from the solutions developer perspective, someone who does not have a lot of experience might question the meaning of every piece of these components. All they want is to have a yes or no response for whether a user is authorized to use a web service. They have no need to customize any of this and hope that an out of box solution with very few number of steps is provided. The challenge here becomes how to balance the need for generic customization with out of box usability.

My take on this, as well as many other matters of simplicity, is convention over configuration. The platform should be configured with numerous defaults. However every default should be overridable. The solution should work out of box with hardly any setup. Admittedly, security is a difficult subject. However as a result, the solution should not be difficult. The burden to simplify the implementation is on the platform developer. If a platform wishes for solutions to be very secure, the burden is placed on the platform to make it easy. If not, solutions developers will begin to take shortcuts. This is now beyond the technology, it is the fault of the people who compromise the security of the system.

[1] Saltzer, Jerome H., and Michael D. Schroeder. “The Protection of Information in Computer Systems”. Proceedings of the IEEE, Volume 63 Issue 9. 1975.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s