jump to navigation

Examples of Protecting Data in thin clients September 15, 2013

Posted by bkrugman in Security.
trackback

In the “The Protection of Information in Computer Systems” [1] paper the authors go over different methods, and different ways of thinking about how to secure data within various computer systems.  I am going to focus on methods that I believe can secure data within a thin client application.  The thin client can be represented by an application on a web site, mobile device or even a personal computer (PC).  There are multiple ways to that I can see to secure data on thin clients, but I am going to focus on leveraging internal security groups via an LDAP setup where the digital persona of the person logged into a device is used to determine the level of data access that they have.  Also the second method that I am going to look at is to use a user login on the specific application to determine a person’s data access.  To ensure some data security and to add an overall level of security to the applications, I am going to be working off of the assumed backend being an internal/external web service operating within a web server that has adequate SSL certificates to ensure that the data that is being passed between the thin client and the web service has some level of encryption to attempt to limit packet sniffing and data extraction based on the communication between the two points.

The example that will be viewed is based on a company setup where there are multiple departments that work with the company’s member base (consumers) to ensure that they are having their needs met.  In this type of example the users of the application will be accessing an internal application, which allows for the leveraging the LDAP setup that currently exists within the company to determine what level of data access each person deserves.  The first level of data access could be a general default access that any validated users within the network are able to access.  This type of information would allow them to see how long a member has been waiting for someone to help with their needs.  The next level of data access would be represented by the people who have the one on one interaction with the member.  These users would have access to more detailed information about the member, such as personal information and what products/services they are currently using from the company.  The final level of data access would provide the highest level of access that would provide not only member details, but also information about the member communication, who worked with the member, how long the member had to wait to be helped and how long the member was being helped.  This type of information needs to be very locked down, because you would not want other people within the organization that deal with the members to know what their peers are doing especially if things like bonuses, and evaluations are based on the information.

The three data access layers will be setup as a security group for each level of data access within the internal structure.  That way, if different employees within the company need to have data access, it makes the setup much easier for the IT Staff and helps to reduce the amount of maintenance required to ensure that the correct people have the correct access.

For the second example of showing different ways to protect data within a computer system, I am going to outline a web and mobile based application where the users are required to login to the application to enter their time, expenses and monthly salary.  This example is on the other side of the data security spectrum from the first example, because rather than being able to rely on a user profile that is managed by LDAP the application is going to consume the user information and determine what data access they have based on a user security database that is separate from the main database.  The security database is maintained by users that have the highest level of security.  With this application the data security is broken up into three groups.  Something that is different when comparing to the first example is that there is no data viewer group that is open to any validated user.  This is because with the application focusing on time, expense and salary entry the application only wants to display the logged in user’s information to ensure that other employees are not able to see how much a person makes and other privacy concerns.

The first security group is for sub-contracted employees.  These employees will only have access to enter how much time they worked per day and submit any expenses that are incurred.  They will not be able to set how much salary they can take due to a contract being negotiated and signed stating exactly how much they will be getting paid per period.  For the second security group you have full time employees.  Users within this group are able to enter how much they worked per day, submit expenses and mileage, and decide how much they want for the months salary.  Both the sub-contracted group and the full time group will only have access to the user’s individual expense and time information.  They both are able to view any expense documents associated to their individual expenses, but are not able to see any other users information.  The final security group is the Administrator group.  This group has full access to all of the users’ data, in case they need to review work and expenses, as well as submit their own personal monthly information.  The administrator group is the users that will be creating the paychecks, submitting any invoices for work done, as well as managing any Purchase Orders that the company has for work done to ensure that all of the information that is being sent is accurate.  Another aspect of the administrator security group is that they are the ones that are in charge of managing the individual security of the employees.  Unlike the first example where the IT department is in charge of the security, in this example users of the application are the ones that will actually be maintaining who has what level of access.  Part of the reasoning for this is that the application is on an external location that will be hard to require company user impersonation for the security access without opening up additional security holes that could compromise other data within a company structure.

Throughout this post I have displayed some of the examples of what was shown within the “The Protection of Information in Computer Systems” [1] paper.  I focused on two different implementations of how to secure data that can be implemented within most organizations.  Both operate off the same base level security model, which is to group sets of users into different data access layers.  Even though they are implemented differently both use the same underlying principle to achieve the end goal.

References

[1] Saltzer, Jerome and Schroeder,  Michael D. “The Protection of Information in Computer Systems”. Sept. 1975; 1278 – 1308. Available from: Proceedings of the IEEE  (Volume:63 ,  Issue: 9 )

Advertisements

Comments»

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

%d bloggers like this: