The significance of the 'warning' message at an organisations logon screen extends beyond the 'immediate effect' that it is intended to achieve - which is to alert the system user that they are 'at' a private logon screen, that they should not proceed unless they have been authorised to do so, and that authorised persons who do access the systems will need to abide by certain conditions and standards of behaviour. The 'extended' significance lies in it's ability to affect the likely success of any attempt by the organisation to prosecute (or otherwise proscribe) anyone who logs on, or attempts to log on, where they are not authorised to do so. Effectively the message is intended both for the person who encounters it 'on the system', and for a courtroom full of lawyers.
Organisations which have information or system assets that they wish to protect should anticipate the real prospect of malicious activity directed against them, and acknowledge that they may become embroiled in the legal process. Even in cases where organisations do not anticipate that they would use legal sanctions against malefactors, they may be 'dragged' into legal action as a result of prosecutions initiated by the police, or by third parties whose data or systems have been compromised as a result of the malefactor's activity within your system. Indeed, in the case where an organisation was a custodian of data, and the data was 'damaged' by a malefactor operating improperly within the organisations system, the 'owner' of the data might take action against both the malefactor (for their direct contribution to the damage to the data) and the organisation (for failing to secure the data against intrusion). The significance of the 'warning message' in this case is not that it has 'prevented' the intrusion (obviously it has not) or that it has entirely 'absolved' the organisation of any liability for letting the malefactor 'in' (it probably won't), but in that if it is worded incorrectly, the malefactor may be able to 'wriggle' out of the charge altogether on a technicality and leave the organisation to face the wrath of the data owner alone.
One might conclude from this that the warning message has to achieve two different, in some senses incompatible, things. Firstly to give the system user clear warning that they should not proceed unless authorised, and secondly to do so in a way that satisfies sometimes arcane legal principles regarding evidence, intent, and reasonable doubt. Any organisation which has information or system assets that they wish to protect should take properly qualified legal advice regarding the format and composition of any logon warning messages, to ensure that it achieves it's intent in the context of the applicable legal jurisdiction. Organisations should not assume that 'borrowed' warnings from other organisations will be inherently 'legal' or adequate to their specific needs, or valid in the applicable legal jurisdiction. While this article will go on to make general observations about the nature of logon warnings, this article is not intended to constitute specific advice to organisations intending to construct logon warnings, and the author takes no responsibility for any action taken by any organisation in respect of their logon warnings, or for the consequences of any of those actions. Organisations are directed to the fundamental principle - seek properly qualified legal advice.
The Logon Warning can be broken down into various elements. There is the warning to the system user that they have arrived at a logon screen, that their behaviour at this screen, their ability to move to the system which lies behind the logon, and their behaviour in that system which lies behind the logon are all subject to conditions that the system user has to accept or 'leave' the screen.
An interesting question arises at this point. It is one of the principles of security (particularly of systems facing 'the public') that the logon screens (and any error messages associated with them) should not give the system user any 'unnecessary clues' that might enable them, or assist them, to break into the system. The ultimate expression of this is the blank logon screen. However the blank logon screen (ie just the logon field and the password field and no other text) does not allow the organisation to 'impose' conditions of use on the system user (it would not be sufficient - legally - to simply say 'don't logon to this screen', as the absence of the name of the system or owner would make it a defence that the person logging on 'did not know that it wasn't where they were meant to be'). One way around this is to use a 'front company' to disguise the identity of the real owner of the system that lies behind (but being careful to ensure that the front company is a valid legal entity which is able to use the legal system to enforce sanctions against malefactors, and to describe a legal arrangement between the front company and the system owner so as to make malfeasance against the system no matter where it occurred in the system an offence committed against either the front company or the system owner or both. The other method is to have the initially minimal logon screen, which leads to the 'fully populated' logon screen that contains the appropriate warnings.
Getting back to the elements, clearly identify the system and the system owner (as the owner of the system) and use this title consistently and in full each time it needs to appear. This (generally) takes up less real estate on screen than one of those "on this page references to 'we' and 'our' refer to XXX etc". Any sloppiness here can lead to 'technical' problems in prosecuting someone, which could lead to a case collapsing. True, it might be possible to persuade the court of the intent of your warning (as the owner of the system), but the court will be left with a clear impression (coming from their 'legal' perspective) that you haven't chosen your words carefully, which a defence team might suggest is a carelessness that spills over into your management of the entire security system.
Explicitly describe how logging on at this screen will lead to a system or an environment belonging to the (previously) clearly identified system owner. Clearly state that you collect information about people who logon, or ATTEMPT to log on to this screen, and the circumstances in which you might use this information (failure to do this may make your evidence about attempted 'break-ins' inadmissible in some legal jurisdictions). Statements about monitoring people 'inside' the system are not adequate as the monitoring in this case is happening 'outside' of the system and potentially involves an unauthorised person who has not signed any waiver regarding being monitored, or agreement that the results of that monitoring might be used against them. Give the person who has arrived at this screen a clear 'exit path' and explicitly direct them to this exit path if they do not accept the terms outlined on the logon page.
The warning should be clear about the consequences of any unauthorised access, or attempts at unauthorised access. Reference to specific legal sanctions is possible (including maximum penalties), and in that case the wording should be something along the lines of "take action, potentially including but not limited to, criminal prosecution under the xxx ACT (maximum penalty $xxxxx or xx years imprisonment)". If you get specific you may be under an obligation to 'keep it accurate' or run the risk of 'voiding' the warning. It may be possible to simply state, "prosecute and/or seek recompense for damages to the maximum extent permissible under the relevant regulation or legislation". Getting good legal advice on this is very important, but failure to mention 'consequences' at all is fairly clearly a major failing.
While we are at it, it might be worth mentioning that caching the logon name (and even the domain if it appears) can destroy an otherwise rock-solid prosecution. It has been accepted as a valid defence that the person who is alleged to have broken into the system 'didn't notice that the logon name on the screen was not their own'. In this case the defence asserts that the password of the person who is alleged to have broken into the system was simply - coincidentally - the same as the person whose logon appeared on the screen. System administrators can't disprove this assertion, as they almost never have access to the unencrypted passwords. Which highlights another concept - if you do have a case of identity theft, as soon as possible get the 'real owner' of the identity to verify their current password before witnesses (effectively the only way to do this is to get them to logon with it) before you reset it. Otherwise your (instinctive) reaction to reset the password, or to 'accerlerate' the normal password refresh cycle to prompt the system user to change their password, destroys part of the evidence. Incidentally, you (I'm assuming I'm talking to a Security Manager) will need to indemnify the real identity owner against any consequences of revealing their password to the witnesses, and (probably) the witnesses for receiving the password, and probably obtain one from fairly high up in your organisation to allow you to (a) request the person to reveal their password and (b) empower you to grant indemnity. Complicated isn't it? But if you don't get the password you might damage your case, but in getting the password you might just demonstrate to the court that your security system is routinely subverted, and that the security manager is complicit in that.
Returning to the warning text; again get good advice about what jurisdiction your logon screen is actually subject to. If the logon screen is accessible from the internet you need to be mindful of which jurisdiction applies, in an extreme case the person attempting to logon, the owner of the system, and the server hosting the page may all be located in different countries. It may be possible to insert a 'generic' all-encompassing jurisdiction statement (eg "to the full extent of the law under applicable jurisdictions") but you should defer to qualified legal advice on this point (as in all points regarding the format or composition of the warning message).
If proceeding to logon takes the system user through to an area where they are subject to some 'conditions' be explicit about the connection between the process of logging on and an implied acceptance of those conditions. Some systems interpose a manual step, requiring the system user to click an "I accept" button to explicitly accept the conditions. As a systems designer you have to gauge whether the added step is worth the greater certainty in court that someone has breached their undertaking to abide by conditions of use. Include a reference to where the full text of those conditions is kept. Generally they are too large to include on the initial screen, but it is better to put a direct link to them (using hyper linking) in the message rather than refer them ONLY by document or webpage name or by some relative reference to a location (eg 'the next screen'). The ideal is to do both. The point here is to persuade the court that the system user has reasonably easy access to where those conditions were stored. Again you want to avoid creating an impression in court that you (as Systems Manager) 'assume' people know where to find things. A defence team will extrapolate from that that you are likely to 'assume' people know what they are allowed to do in the system and suggest that you have probably (consequently) failed to check that the mechanisms that ought to 'make that happen' are working properly.
The 'conditions of use' are a complex discussion in their own right, but in respect to their being 'referenced' from the logon page, the Security Manager should be mindful of the 'evolving nature' of those documents, and the need to keep certified copies of those 'conditions' for as long as the statutory periods applying to the sort of crimes that might call for their production in evidence. Ideally those people who are subject to them (and this won't be possible in all cases - as you may have publicly accessible websites which impose 'conditions' but where you never have physical contact with the system user) should sign, and the signed version should point to the same electronic copy that the logon page points to, and be explicit in putting the onus on the system user to check for any updates. To reinforce the courts view of the 'reasonableness' of this it would help to have (a) an alert process when the conditions change (and note that banks will contact EVERY customer by mail in these cases), and (b) some kind of indication in the system (at the logon page or the page that the logon page leads to) of a change and of the effective date of the document.
Security Managers should also be carefull that the organisation has not neglected to create a very explicit policy on monitoring. The most regulated organisation in the world will not be able to successfully prosecute someone who is absolutely clearly in breach of a 'condition of use' if the method of obtaining that knowledge is ruled by the court to be improper or illegal. Clear legal advice in this area is very difficult to obtain, as there is relatively little legislation, but a great many evolving principles based on case law, and varying interpretations of existing privacy and human rights legislation. This shouldn't stop you from seeking legal advice of course, but if that is unproductive you might - at least - have a clearly stated policy that includes reference to what might be monitored, who might be monitored, the circumstances in which that monitoring might take place, who will do the monitoring, who can authorise the monitoring, what procedures will be in place to secure/validate the information obtained by monitoring, and the protocols applying to the use of the information obtained through monitoring. While you're at it you might include provisions for dealing with situations where monitoring is conducted without authorisation, or where information gained through legitimate monitoring is misused. Courts have observed that where there is clarity about the organisations intent, and where informed agreement has been obtained from staff, issues relating to monitoring - and issues revealed through monitoring - can be dealt with much more directly. Note, however, that if your organisation is subject to legislation covering monitoring in workplaces the legislation usually includes a provision to invalidate any agreement between parties that is contrary to the intent of the legislation. The other cautionary aspect to this is that your organisation, giving regard to the international nature of law and trade, might be subject to jurisdictions which are not immediately 'obvious'. Again, there is no substitute for good legal advice.
Comments