KES Standard Operating Procedures

[Prudence]

Data Storage and Management:

Space Stations/Shipyards: Should the shipyard or Station orbit a planet or other celestial body (asteroid, moon, etc) and should the KES have a facility on the celestial body in question, all data accessed by the station is housed on data farms and servers in the terrestrial facility. A steady custom-encrypted (encryption key created by KES engineers as to not allow the existence of the encryption key to be had by anyone else) holonet link is established between the station/shipyard and the servers. This is to maintain security and continuity of data between multiple sources. Should the shipyard/station lose connection to the servers data can manually be loaded into the datacore of the station through a backup, or a nearby ship. However until such a load happens the station/shipyard is devoid of all KES data.

Should the Shipyard/Station not orbit a planet or other celestial body (as defined earlier) or should the planet and or body in question not host a KES base, the datacore aboard the station/shipyard is loaded with a copy of the entire KES databank. This station is then linked to all other KES servers / datacores via a custom-encrypted connection through the holonet. Should this connection be interrupted the station/shipyard will continue business as usual until connection is resumed. Then data will be synced between the two sources, KES Supreme Commander will determine which source is to overwrite the other source.

All files are cached during use on station computers, and then changes are transmitted to the server once done, or upon a save. Connection with the server is similar to an IRL TCP connection, in which a three way handshake is established and data integrity is valued at all costs. If something interferes with the connections before a proper sync can be made with the server changes are kept aboard the station/shipyard and sent to the server at earliest possibility.

Ships: All KES ships, frigate size and larger, are equipped with a full datacore of all KES data. These sync via custom-encrypted holonet connections with other servers to establish continuity. Corvettes carry pared down datacores, with all data deemed non-top secret kept onboard unless KES high command should deem otherwise. Fighter craft and frigates carry no KES Datacore, and access all KES data through custom-encrypted holonet connections to nearest KES datacore or server. Access restricted to individuals possessing proper KES security token, biological implant, credentials, or biometrics. Fighter craft have no access to KES servers or datacores. ​

Patrols:

During standard patrols should KES forces encounter minimal resistance they should consult the RoA set by KES HighComm for the operation. Should the RoA state to engage if fired upon, then KES personnel should return fire, should the RoA state to ignore any non threatening fire, KES personnel should ignore attacks. Should a KES vessel become compromised physically, or go down, KES vessel in lead, if capable, should break rank to retrieve downed troopers. Field commander present will lead resistance against armed resistance, should it be necessary. Once downed troops are retrieved KES forces should return to HighComm for immediate debrief and new orders.​

Disciplinary Action:

Should a KES personnel be found in violation of required KES conduct, a series of evaluations will be used to determine punishment. Should action take place, and become observed, during a state of emergency or warzone, the following is inapplicable and one should consult emergency disciplinary protocol.

• 1st class: A 1st class offense is a minor offense. Usually pertaining to disrespecting a higher officer, being found out past a required curfew, or in restricted area. Defying a direct order with no dire or severe consequences is also 1st class. 1st class offenses are to be dealt with by CO. Usually punishable with rank demotion, additional work, pay dock, etc.
• 2nd class: A 2nd class offense is typically more serious than a 1st class offense. These are such as theft, defying a direct order with consequences that caused non critical harm to ships or KES assets, or harm that is not lethal to KES personnel. Can be punished with time in brig, or 1st degree punishments.
• 3rd class: A 3rd class offense is the most serious of them all. Usually encompases murder, attempted murder, and manslaughter. Defying a direct order with critical damage done to KES assets, or lethal harm done to KES personnel. 3rd class is punishable with execution after trial by KES tribunal, or any of the aforementioned punishments.
• Emergency Disciplinary Protocol: When in an emergency or warzone, things become more critical. 2nd and 1st class offenses are punished with brig time, or time spent in cuffs to prevent further damage to KES assets while emergency in place. 3rd class punishment are capable of being punished with immediate execution, or injury by SO or HighComm

Spoiler: Notice

All custom encryption keys are a PKI type key. With a PKI used, and modified with additional KES overlays and such to add an obscurity to it inorder to make it more difficult. All holonet connections pertaining to dataflow are assumed to be encrypted using this custom encryption unless specifically stated that it does not use it. Omission is assumed to infer that it is still there and accidentally omitted

​

 

[Grim]

Thinking on a production level and knowing that KES has droids do the vast majority of the work, wouldn't it still be best to have a local store of some of the most used data? I mean if you have to pull say a file a thousands times a day that is a lot of wasted data flowing up and down from a planet. Especially for something that your designers and engineers are going to always be working on. Would be a real shame if that new ship is found to have a terrible safety issue, the engineer fixes it sends it down but crap a storm or heavy cloud cover causes the Data to be lost or corrupted. At the very least you would want a Caching Proxy on the station to facilitate any manufacturing needs.

Is it a generic Encryption standard you are using like a PKI type set up or is it a custom made encryption standard. Because if it is the later that in and of it self might make it less secure as its not/has not been tested properly for any real weaknesses.

 

[Prudence]

Thinking on a production level and knowing that KES has droids do the vast majority of the work, wouldn't it still be best to have a local store of some of the most used data? I mean if you have to pull say a file a thousands times a day that is a lot of wasted data flowing up and down from a planet. Especially for something that your designers and engineers are going to always be working on. Would be a real shame if that new ship is found to have a terrible safety issue, the engineer fixes it sends it down but crap a storm or heavy cloud cover causes the Data to be lost or corrupted. At the very least you would want a Caching Proxy on the station to facilitate any manufacturing needs.

Is it a generic Encryption standard you are using like a PKI type set up or is it a custom made encryption standard. Because if it is the later that in and of it self might make it less secure as its not/has not been tested properly for any real weaknesses.

Ahh you did catch some technicalities and failsafes j missed. I'll address those as soon as I can. Thanks!/:)

 

[Prudence]

Thinking on a production level and knowing that KES has droids do the vast majority of the work, wouldn't it still be best to have a local store of some of the most used data? I mean if you have to pull say a file a thousands times a day that is a lot of wasted data flowing up and down from a planet. Especially for something that your designers and engineers are going to always be working on. Would be a real shame if that new ship is found to have a terrible safety issue, the engineer fixes it sends it down but crap a storm or heavy cloud cover causes the Data to be lost or corrupted. At the very least you would want a Caching Proxy on the station to facilitate any manufacturing needs.

Is it a generic Encryption standard you are using like a PKI type set up or is it a custom made encryption standard. Because if it is the later that in and of it self might make it less secure as its not/has not been tested properly for any real weaknesses.

It would be a slightly modified PKI. Like KES engineers would take a PKI, and then probably overlay some KES protocols over it just to make it more obscure, and then implement it. I also edited.