That is your first problem then, and is typical of bottom up design.
I'll put this as clearly as I can. Local units are currently using a plethora of various shoddy web solutions, ranging from outdated and vulnerable free scripts, modified versions of existing software that never went though the proper auditing and ending with solutions that are completely inappropriate for the job.
You need to adopt a structured analysis and design methodology (SSADM, PRINCE2 or whatever takes your fancy) if you want a coherent and cohesive solution that would facilitate security.
Yes, there does seem to be 1970s,1980s mainframe thinking here. Dumb terminals, flat file architecture and all your eggs in the one basket :shocked:
The only other thing i can think of is the Cloud computing...where the cloud never gets compromised :eek7:
Certainly not a military solution or even defence sector, as there is an implied requirement for all units to have remote access, and you are presenting a single target for a one shot kill.
My experience in the defence sector indicates that there is a need for two distinct types of network:
1. The General Network. This basically handles unclassified material with various subdivisions for LAN, WAN, and internet etc. It is secured as all networks should be, but does not permit access to anything rated as classified.
2. The Secure Network. This handles all classified material and is only accessible on site (where physical security can see that you are not under duress). No external connections are permitted, nor is connection to the General Network. Connectivity is wired not WiFi.
Basically, if a site or command centre is compromised then only data pertinent to it, is compromised. You would have to roll-up all locations to get the big picture, and to prevent re-grouping.
If your system is fundamentally secure, then it doesn't matter how many implementations of it you have; they are all equally secure from a systems viewpoint, provided that they have been deployed correctly.
focus is put on maximum security, privacy, constant auditing and strict limitation of access. Individual units are incapable of properly securing their data by their own. Instead of a number of sloppy and potentially dangerous solutions the idea is to replace all of those by one system that implements the level of security otherwise not attainable by individual units alone.
1. Hardware and software configurations should be irrelevant. We are talking about wiping hard drives here.
On the other hand permanently and irrecoverably erasing the data present on dozens of different servers, as it is today, different software and hardware configurations by the appointed people, whose computer skills may often be insufficient, is a recipe for disaster - assuming there's still power to wipe anything off some remote commercial server.
2. If people's computer skills are insufficient, then it is only surpassed by the inadequacy of your personnel selection process. Bloody well train them!!! Anyways just how long do you think it takes to train someone to wipe a hard drive, or pull it from a server and consign it to a furnace, a vat of acid, slice it with a blowtorch or zap it with an electro magnet? I hope that you will notice that only two of those require "power" and there are such things as portable generators and UPS systems these days. :rolleyes:
Oh! I read your post with very great attention, and I also read between the lines, given that the writing was in plain text if not brightly coloured capital crayons. This is not about security, this is about an internal power struggle where someone is trying to gain control of, and wrest autonomy from, remote units :cool:.
In case it's still not perfectly clear: The server and database is a bureaucratic crutch, not a combat implement. Never was meant to be one. If you'd read my previous post with a bit more attention you'd realize that I stated that in the event of a SHTF
You miss my point; I am not interested in specifics at all, just in general principles, and then only insofar as they would impact on data sensitivity.
I'm not at liberty to discuss the specifics of how would or how should particular situations be addressed. Neither am I the person to make those calls nor is this a place where I would engage in debates of this kind.
Personal data that is out of date is pretty useless so , if when the excrement hits the venturi propeller, everyone heads for the hills, so to speak, the locational and contact information will no longer be sensitive?
This can have a significant impact on your database design, if you use a relational database rather than a flat file one. With an RDB you can easily segregate sensitive information from that which is not, and fine tune your security procedures. It would also provide an opportunity to spread disinformation to any potential hostile, particularly if they only get to see part of the database? :D
As for specifics: "special screws"????????? total waste of time if you look at the equipment that fire and rescue use to free trapped people.
Nowhere have you mentioned a strategy for the destruction of backup copies, at least one of which should be held at a remote location. Backups are almost as dangerous as the data on your live systems.