Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 348
  • Last Modified:

EXTEND LEISURE CARD TO ACCESS MORE THAN ONE DATABASE

I have been asked this question;
Imagine that  you are a computing professional asked to advise a local authority. This local authority currently offers a ' leisure card ' which is used for access to sports facilities. It is now considering extending the use of the card other services, for example libraries and housing. The card will be used in conjunction with a central database holding core personal information such as name and address of the card-holder. This central database will in turn link to other relevant database, such as those of the library service and the housing department, which will be able to access the core information on the central database. Write a report(2000 wr) for the local authority  outlining the issues which they should take into consideration in deciding whether or not to take this idea forward.
My questions;
1- Should this authority take this idea or not and why?
2- where can i find a good references about this subject( name books and website if you can).
thank you very much
ahmed
0
alqaoud
Asked:
alqaoud
1 Solution
 
Karl Heinz KremerCommented:
This sounds a lot like homework ...
0
 
ArrummzenCommented:
1: The idea is not bad. But it must be done very carefully with systems not 'trusting' each other. With one database, you have one site to different. With two, two sites to defend and so on. I would take into consideration one of the following
A: A centralized database, put EVERYTHING on this database, have the other sites access this database, provide access levels so that for example the library can not view financial information and the housing department can't view overdue books.
B: Provide a centralized database with basic information name, number etc. and allow each site to maintain its own information. Do not let the branch databases (ones at the library, sports facility, etc) access the root database (the central one). for anything other than name and number. Do not let them make changes. In this way the beaches will only have access to their own information, you will have the same card work at all locations but the card used at one location will map to different data than it will at another- for example -
card1000 used at sport facility - Access record8342
card1001 used at sport facility - access record8357
card1000 used at library - access record4235
card1001 used at library - access record4680

You give each person a number (on there card) and have each site handle the number separately. You may allow sites to read some information from the root, such as name, picture etc or not have a root at all and make each branch keep its own record. Its more secure to have each branch 100% separate, but having a root database hold information that is global to all sites (name, picture, fingerprint etc.) saves space and ensures that the data is consistent across all sites (so for example, if someone losses 70 pounds and wants to change the picture in the database, they don't have to go to each branch and change it, they only have to go to one and the changes will be reflected in all sites).

2: In my experience more attacks occur because of flawed implementation then do because of flawed architecture (although flawed architectures exist. They are rare.). Most systems provide a password, the passwords existence is not the problem, it is that the programer (almost always by mistake) created a bug in the password system, so that an attacker can get around it. Whatever you do, make sure that a network of trust mistrust is established. Do not allow the branch at the library trust full the branch at the sports facility (because it may have been compromised).

As for things to take into consideration
A: How much do you trust the employees at each branch
B: How easy is it to physically access the network/computers at each branch (wireless networks are a big no, if they are installed, keep them separate from the database network, for example if you have a wireless network at the library for people to use with their laptops, do not put the database/information systems on the same network, don't even connect them, use a 100% separate wired network.)
C: What in information will be held at which site
D: Which sites will be trusted to access which information
E: Implementation. What OS will you be using. Which database system?
F: Don't trust anyone security mechanism. All systems have personal farewells, all networks IDSs (like snort), all networks separated by fire walls (that allow only your database protocol to pass, no HTTP, no FTP etc) ,  network must not be connected to the internet, All workstation are locked down. If they are Windows systems, you can write your database access program as a screen saver, so that ctr+alt+del are disabled etc. If using *IX, write it as a standalone X11 program, run no Window manager. If the terminal is idle for > 5 minutes have it lock. Requiring a password. Allow system operator only enough control to make changes they need. If they want to change someone’s name or picture, they must call the root office and have the changes made there and encrypt everything.

Build the system. Try and break into it, make changes, try to break in agin, make changes, try to break in agin. I have never came across a Network I couldn't break into, (I have never broken any laws in trying). All Networks I have seen have a flaw, and even if I find one that doesn’t have a flaw, there is always social engineering (this is why you need a strong information policy, NEVER give out passwords over the phone) Just don't do anything stupid.

Just some random thoughts.

Thank you for your time,
Arrummzen
0

Featured Post

New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now