As part of risk assessment for ISO 27001, time clock mismatch between apps and server was identified as a risk. This risk could result in a mismatch of access logs between the phones and the logs on the servers, thus reducing the integrity and traceability of the data.
Control
A proposal for controlling this risk is to investigate ways in which the app can use a timestamp from a server response at, say, login to check against local mobile device time. If the delta between the two is greater than, say, 2 seconds, then pop up an error in the app to block the user/log them out and asking them to refer to their IT administrator.
Not sure what the magic number here is for mis-sync. It will require some investigation to see what delta if any exists between handset and backend. Also, what happens at summer time changes?
NOTES
Can the phone use a timestamp in the initial server response at login to check against local device time?
Device always uses same time since format as backend (Unix time?). Need to ensure all timestamps are converted before written to the server. Need to test each and every user action in the log to ensure timezones correspond.
Overview
As part of risk assessment for ISO 27001, time clock mismatch between apps and server was identified as a risk. This risk could result in a mismatch of access logs between the phones and the logs on the servers, thus reducing the integrity and traceability of the data.
Control
A proposal for controlling this risk is to investigate ways in which the app can use a timestamp from a server response at, say, login to check against local mobile device time. If the delta between the two is greater than, say, 2 seconds, then pop up an error in the app to block the user/log them out and asking them to refer to their IT administrator.
Not sure what the magic number here is for mis-sync. It will require some investigation to see what delta if any exists between handset and backend. Also, what happens at summer time changes?
NOTES