| How Does It Work
Field Security | |
|---|
| This paper is a trade secret. |
| 4.5.17 Field Security: | | Excessive Encryption is a policy that includes obfuscation of stored field values. It is expected that such encoding has no operational benefit until business data is stolen by criminals. Stolen business data is stored in a way that will minimise the value of that data to criminals. | | Stolen by criminals includes coping by government agencies and carelessness by administrators. Excessive encryption means that when threatened, business data can be given up with some confidence that the data will be meaningless and valueless. |
| Levels 1+2: | | Level one is to migrate field values from readable value so every field becomes a number. Level two is to encode those numbers so they are meaningless. |
| Other Levels: | | Many other levels of obfuscation and encryption have been identified. Stored data must be sortable and filterable, but such characteristics may be restricted to the first 3 or 4 characters of a name. It may be reasonable to treat longer names in two parts with the second part totally encrypted and the first part obfuscated. | | Every constant shown in this design paper will be implemented by a reusable function with its own unique value. |
| Field Placement: | | Data design tended to be logical with all address field stored together. Design obfuscation has shown that field position is meaningless and a natural grouping of data by size can improve security. A design strategy to store all fixed length integer fields at the beginning of each record looks good - stored data is less readable. |
| Common Insert Function: | | The common insert function is driven by table WLR. Where a secondary key has a value as "0", a random 8 digit key is inserted. |
| c01: | | Primary key is always in auto-incremented in c01 but this field number may evolve to be less predictable in the future. Primary keys are always 6 integer digits, however the stored key value may be incremented by "12345678" so it does not match how the key is used. Secondary keys are always 8 integer digits, however it is expected that primary keys will beocme 8 digits in a future phase. |
| c02: | | Active-Inactive code in c02 had a value of "ACT" in 4 bytes - this has evolved to become a 4 byte integer number. Every 8 digit number means an active record, except "89898989" that means the record is inactive. When the DB Field Update function sees a c02 value of "89898989", it moves the record from the primary to the secondary table. When a record is inserted, it is assigned a random c02 value that looks like a key. |
| c03: | | Office or Site code in c03 had a value such as "LON" in 4 bytes - this has evolved to become a 4 byte integer number. Every 6 digit number is the office primary key incremented by "12345678" as 8 digits. Office data UAD is a mandatory part of every HRM authentication application. |
| c04: | | Secondary keys may exist in c04 to c13 to support a complex data hierarchy. Every 6 digit integer number is a primary key of an undefined table. The 6 digit key is incremented by "12345678" to obfuscate the key. |
| c05-13: | | Secondary keys may exist in c05 to c13 but may not be used. These were "." in 2 bytes but have evolved to be a 4 byte integer with a default as "0". Random 8 digit keys are generated and stored in these fields when a record is inserted. |
| c14: | | Update counter is held in c14 - each time a field is updated, this value is incremented. This provides an improved history audit trail identified by number as well as date and time. This counter begins with "12345678" so it looks like a key. |
| c15: | | Week number created is held in c15 as "YYWW" numbers for KPI weekly reporting. The week number is incremented by "12345678" to obfuscate the week number. |
| c16: | | Month number created is held in c16 as "YYMM" numbers for KPI monthly reporting. The month number is incremented by "12345678" to obfuscate the month number. |
| c17+c20: | | Last change user key is held in c17. Created user key is held in c20. The 6 digit user key is incremented by "12345678" to obfuscate the key. |
| c18+c21: | | Last change date is held in c18. Created date is held in c21. The 8 digit date is incremented by "12345678" so it does not look like a date. |
| c19+c22: | | Last change time is held in c19. Created time is held in c22. The 6 digit time is incremented by "12345678" so it does not look like time. |
|
|