| 4.4 Access Control
04. Obfuscation | |
|---|
| 4.4.04. Obfuscation. | | 1. The solution is encrypted replicated data, but many steps are part of the journey. All business data must be encrypted and obfuscation is just one layer of that encryption. | | 2. All field values that can be stored in a four-byte integer will be stored as an integer. When a very large number of different field types are all stored as integers, it can be hard to differenciate, to comprehend and to begin a decryption attack. | | 3. Many text fields are pseduenomised and replaced with an integer token. Many quite different tokens have identical values so it is hard to distinguise what is what. |
| 2. Date. | | 1. Many date fields need to be stored and these must be obfuscated using alternative encryption methods where more than one plausible decryption value could exist. | | 2. All dates are only internally handled as YYYYMMDD to be formatted for display. | | 3. The date value is given a "2" suffix so "20170717" becomes "201707172" as field-3. | | 4. The primary key value is given a "2" suffix so "123456" becomes "1234562" as field-4. | | 5. Fields 3 and 4 are added together as "201707170" + "1234562" = "202941734" as field-5. | | 6. Fields-5 digits are reversed as "437149202" as a 9 digit integer that cannot have a leading zero. | | 7. "17 Jul 2017" is stored as "437149202" in this record and as a different value in other records. |
| 3. Decimal. | | 1. Many decimal amount fields need to be stored and these must be obfuscated using alternative encryption methods where more than one plausible decryption value could exist. | | 2. All decimals are only internally handled as pence to be formatted for display. | | 3. The decimal value is given a "01" suffix so "123.45" becomes "1234501" as field-3. | | 4. The primary key value is given a "01" suffix so "123456" becomes "12345601" as field-4. | | 5. Fields 3 and 4 are added together as "1234501" + "12345601" = "13580102" as field-5. | | 6. Fields-5 digits are reversed as "20108531" as a 8 digit integer that cannot have a leading zero and by design, looks like a date. | | 7. "123.45" is stored as "20108531" in this record and as a different value in other records. |
| 4. List. | | 1. Many list fields need to be stored and these must be obfuscated using alternative encryption methods where more than one plausible decryption value could exist. | | 2. All list value are only internally handled as 3-digit tokens to be formatted by lookup for display. | | 3. The list value is given a "01" suffix so "123" becomes "12301" as field-3. | | 4. The primary key value is given a "01" suffix so "123456" becomes "12345601" as field-4. | | 5. Fields 3 and 4 are added together as "12303" + "12345603" = "12357902" as field-5. | | 6. Fields-5 digits are reversed as "20975321" as a 8 digit integer that cannot have a leading zero. | | 7. "Ready" is stored as "20975321" in this record and as a different value in other records - this is not reversable. |
| 5. Email. | | 1. Email field values are personally Identifiable Information (PII) that must be protected by law. Every email address has a prefix and a suffix that are treated in different ways. | | 2. Each email suffix is a domain that is internally handled as a 6-digit pseudonmised token that has its value looked up for display. | | 3. Each email prefix is a type of lower case name that must be character-by-character encrypted as a string of digits. | | 4. The string of digits are extended to a fixed length of 65 digits to prevent guesses based on name length. | | 5. The string of digits are bucket scrambled with a number of different methods and the primary key to make sure that reverse engineering is not practical. | | 6. "fred.smith@gmail.com" is stored as 65 digits and an integer that is unique to this record - this is not reversable. |
| 7. Phone. | | 1. Telephone field values are personally Identifiable Information (PII) that must be protected by law. Every phone value has a prefix and a 7 digit suffix that are treated in different ways. | | 2. The 7-digit suffix is encrypted to an integer using methods similar to a date. | | 3. The 4 to 7 digit area-code prefix is replaced with a 6-digit token. | | 4. "0208 4288366" is stored as an integer token and an integer value that is unique to this record - this is not reversable. |
| 8. Name. | | 1. Name field values are personally Identifiable Information (PII) that must be protected by law. Each type of name may be processed in a distinct way. | | 2. The name must be character-by-character encrypted into a string of digits. | | 3. The string of digits are extended to a fixed length of 66 digits to prevent guesses based on name length. | | 4. The string of digits are bucket scrambled with a number of different methods and the primary key to make sure that reverse engineering is not practical. | | 5. "Fred Smith" is stored as a 66 digit value that is unique to this record - this is not reversable. |
| 9. Address. | | 1. Address field values are personally Identifiable Information (PII) that must be protected by law. Each part of an address may be processed in a distinct way. | | 2. The building (house, flat or suite) name must be character-by-character encrypted into a string of digits. | | 3. The house number or street number-range must be character-by-character encrypted into a string of digits. | | 4. The string of digits are bucket scrambled with a number of different methods and the primary key to make sure that reverse engineering is not practical. | | 5. The street, district, town, county and country are pseudonomised tokens stored as integers like a list field value. |
| 10. SQL vs NoSQL. | | 1. When all business data is encrypted, then SQL filters are not practical. | | 2. All business data needed by a transaction is loaded and decrypted into memory arrays. | | 3. The benefits of SQL no longer exist and NoSQL can be more effective when browse (load) a complete table is the primary objective. | | 4. Spreadsheet functions operate on in-memory arrays to filter and sort data as needed for display - transient indexes can be constructed as needed. | | 5. Update is always one record at a time by primary key, but this can be to an internal array until the transaction is complete and the entire array is rewritten to permanent storage. |
| 11. Replicated Data. | | 1. Encryption is easy because its all in one place where an application is executed, but replication demands access to many other physical places. | | 2. The "database field update" has a long pedigree to keep things safe and secure using a compound URL-like key. | | 3. When a transaction updates a record in one data center, it will fire a complex transaction to other data centers to effect the same update. During the day, record level update may be fit-for-purpose. | | 4. When a transaction completes and rewrites a NoSQL file, it will fire a complex transaction to other data centers to effect the same rewrite. During the night, file replacement update may be fit-for-purpose. | | 5. Each application has a remote database update transaction with long encrypted one-time URL that cannot to copied and reused. The URL contains replicated dates, times and timestamps as the number of time-units since a historical-event - the URL includes CRC checks and has a life cycle of a few minutes. | | 6. Demonstration. When WQMS "soton" project data is updated, those updates can be viewed as replicated in 495-Ltd application. |
| Document Control: | | 1. Document Title: Obfuscation. | | 2. Reference: 164404. | | 3. Keywords: ITIL Obfuscation. | | 4. Description: Authentication with Obfuscation. | | 5. Privacy: Public education service as a benefit to humanity. | | 6. Issued: 13 Jul 2017. | | 7. Edition: 2.2. |
|
|