How to set up your security policy
Why you need a security policy
Signify’s managed authentication services allows organisations to deploy a range of authentication technologies to their networks. Unfortunately the security of an organisation’s network isn’t simply dependent on how technically secure the authentication technology is or how it is implemented. The security is only as good as the processes and procedures put in place to control the roll out, replacement, and revocation of users.
An organisation’s security policy defines what processes and procedures are operated to ensure its ongoing security. This includes:
- When a user has lost/broken their token, how is their identity checked before a replacement is sent out
- When a user has forgotten their PIN, how is their identity checked. This can be the same for token loss.
- Types of credentials available to users, and availability of emergency access.
Signify make creating a security policy easy
Signify has made these decisions and implementations straightforward. We have a standard range of options for each of the above decisions. All the options can be managed via the Identity Management Centre (IMC) by changing the Organisational Profile and the Security Policy. These can be changed whenever the organisation wishes using the IMC. Any changes are automatically reflected throughout Signify’s service, including fulfilment, user administration, and helpdesk services
.
Every organisation will have its own specific security requirements about how they want to manage their users and this usually determines whether they want a single security policy for their whole organisation or different policies for different parts of the organisation. An organisation can be modelled on the IMC as a hierarchical collection of sub organisations so it reflects the actual hierarchy of the organisation. An example: 
This allows organisations to model themselves by geography, offices, business units or even groups of individuals and then if appropriate set different security policies for different parts of their organisation. For example one organisational unit may be required to have RSA SecurID tokens, whereas another unit may be allowed to have SMS passcodes as well as SecurID. It is normally recommended to have a single security policy, but the flexibility of the IMC means organisations can create a policy for their own specific requirements.
Security policy settings
The security policy defines what types of credentials are permitted in organisations (or in each sub-organisation), and also defines a set of helpdesk processes to ensure that an organisation’s security is maintained throughout the lifecycle of each user. It is a fact of life that users will occasionally lose or break devices, forget their passwords and PINs etc. Signify have focused on making sure that the IMC enables these situations get dealt with as a matter of standard daily business for the organisation, with minimal cost to the organisation, easily and efficiently for the end user whilst maintaining the security of the organisation to the level that the organisation wishes to achieve.
The following are the settings that organisations can set in the security policy:
What types of authentication credential are permitted:
The services an organisation has purchased appear in the ‘General Organisations Options’ section of their security policy on the IMC. Using the IMC, organisations can enable the devices they use (selecting with a tick) or disable them by removing the tick. See below:
Passcode OnDemand options:
If an organisation has the Passcode OnDemand service, they can configure how the service is used in the security policy. By default, once the service is applied, all options are enabled, these should be reviewed to make sure they are all appropriate. These options are:
- Delivery method – which devices users are allowed to be assigned with
- Default device – which method of delivery should be the default
- Allow simple PIN Mode - allows the user to enter only the OTP that they receive when they authenticate, as they have already successfully provided their PIN in order to obtain the OTP
- Allow pre-send on authentication - allows the user to automatically receive a new OTP upon successful authentication
- Allow pre-send on expiry - the user will automatically be sent a new OTP if the old one expires before it is used.
- Passcode maximum lifetime – define the lifetime of the passcode
Helpdesk options:
Most of the security policy options apply to the end-user helpdesk. This is because most vulnerability in an organisation’s security with regard to user authentication is in its processes regarding helpdesk calls. You can have the greatest security technology in the world, but if you give the keys to the door to the wrong person then they can walk straight through it. The security policy allows organisations to adjust their security stance between maximum security and ease of use for the end users, the IMC even allows phase increases in security.
Alternative authentication options:
Many helpdesk operations require the user to identify themselves before that operation can be completed. Most of these actions involve replacing one or more of their credentials, e.g. their PIN, password or token. As such, they clearly don’t have all their credentials, and therefore we can’t ask them to log into the IMC, where we could then perform an authenticated session.
Therefore the IMC has a range of methods that can be used to identify the person in the absence of their credentials. These methods, we call alternative authentication.
Within the security policy you can define which or all of the methods are available to identify a user, and how many of those must be used. The IMC’s helpdesk functionality provides a full audit of the whole helpdesk process so that the authentication of the user and subsequent replacement of a credential is auditable and traceable. Alternative authentication includes:
- Security questions – set up how many questions the user will get asked, and how many they will have to get right. (The more they set up, the harder it is for an attacker to research the questions)
- Confirm access to an email address – If a user is sat at their desk, they can simply have an email sent to them, which contains a unique link which if they click, will prove they have access to their email.
- Confirm possession of mobile phone - Ideal when a user is not in the office when they wish to perform their helpdesk action. The user is sent an SMS to their mobile phone, containing a unique reference code. They enter the reference code into the helpdesk (or tell it to a telephone helpdesk operator), to prove that they have their mobile phone with them.
- Confirm identity via a notary – a trusted person confirms the user’s identity. If the user requests notary authentication then an email is sent to all the notaries who have ‘scope’ over that user. When a notary has confirmed a user, the IMC creates a audit log entry identifying the notary as having performed that step.
Forgotten PIN/password options:
The level of authentication for a forgotten PIN or Password can be set differently to that for replacing a physical device. However they are normally set to the same level. The default on the medium security level is to require one of the alternative authentication methods (see above).
Lost/broken token options:
The default security setting for reporting a token lost or broken is any one of the four alternative authentication methods. After the alternative authentication is completed, the user will be able to disable the token. They will then be able to indicate where the replacement token should be sent. The security policy can be set to restrict them to only their registered address, to only their primary address that is registered directly to them, or to allow them to enter any address where they would like the token sent to.
Emergency access options:
Once a user has registered a physical token as lost or broken they cannot gain access to systems until they get a replacement. Where Signify are responsible for sending out replacements to organisations, the replacement is normally sent out the same day that it is requested, and always within twelve working hours. This can mean however that the user is unable to work remotely for at least a day, and sometimes longer if the user is abroad at the time. For an organisation that wants maximum security this is the correct procedure.
To enable remote users to keep working Signify make available a feature called ‘Emergency Access’, of course the trade off here is convenience and productivity for ultimate security. For maximum security, this feature can be disabled, but most customers find the benefits of increased flexibility, especially with its secure implementation mean that it is worth having the feature enabled.
In their security policy organisations simply indicate whether they want to enable emergency access, and if they do, how they want to authenticate the user. They can leave the alternative authentication method as the same as it is to report a broken/lost token, or they can request users must complete two methods to obtain emergency access, which provides an extra step of security before enabling this access.
The security policy in place
Once an organisation has set and configured the security policy to meet its requirements, it simply clicks a button to enable it. The whole policy can then be viewed in its entirety in the IMC providing a quick summary of all the settings. 
This can be copied into other documents if required, enabling it to become part of a corporate security policy if necessary. If any changes to the policy are required at any time, they can simply be edited and settings changed in the IMC