There was always a high quantum of solace in knowing that no remote access was permitted within our organization. I had implemented and was overseeing information security management arrangements which included defence-in-depth, best practice and accredited compliance with relevant standards and best practice. These arrangements operated within clearly defined system boundaries – both logical and physical. The logical system infrastructure was protected within a secured perimeter, and the physical boundary was mainly confined to one large, modern office building with extensive physical security measures in place. When discussing, for example, a new security alert related to the threat of a denial-of-service attack with senior management or colleagues in other organizations, I could explain the countermeasures that were in place which mitigated against the risk to our systems. These included technical countermeasures such as: network-based intrusion detection and network segregation; email attachment blocking and checking and heuristic pattern detection in the anti-malware solution; removable media controls and desktop lockdown; a robust patch management platform; strict access control and user privilege management arrangements; and continuous monitoring of the systems and networks and analysis of the logs. The technical measures were complemented by non-technical arrangements, including robust policies and procedures, with the main system security policy and security operating procedures supported by a number of specific policies (e.g. use of the Internet and incident reporting policies) and a set of individual role-based SyOps. Well-established organization and governance arrangements were also in place with clearly defined roles and responsibilities in respect to security management. Importantly, all of the requirements of the policies and procedures were communicated via a comprehensive user education and awareness programme, so that a culture of good security practice and policy compliance was embedded throughout the organization and supported by senior and line management. So having described the information security management system in place to the chief executive for example, and having explained the assurance that this provided in respect of a newly reported threat or vulnerability, I would usually conclude by adding (yes, I confess, with a degree of smugness): “….and, of course, we don’t allow any remote access”. While there were always enough security issues ongoing to often keep me awake at night during the working week, generally I was able to sleep OK on the weekends. The potential for remote access to provide a means for attackers to bypass our firewalls and access controls and thus gain unauthorized access or deliver malware was one area at least that I did not have to worry about. So imagine that “uh-oh” moment I experienced when I opened an email from a member of the business senior management team asking me to approve the implementation of remote access for the service provider. The first thing I did was say No. Actually, I explained that our policy prohibited remote access. But it can be useful to say no initially to test how real the need is. (I have been asked in the past to approve requests for exemptions from security policy – endorsed by senior management – only to find out by investigating further that alternative arrangements were available, avoiding any security changes and with no less convenience). As well as explaining the policy, I also reminded the senior manger that any such changes needed to be supported by a robust documented business case. As mentioned, what represents a robust business case is often a subjective matter with business managers, but after detailed discussions the business need was documented and endorsed by the senior management team – including by the chief executive. The business case centered essentially on the need for service provider staff to be to be able to access the system remotely to provide 24/7 support for a major tech refresh project. The project was otherwise in danger of slipping, with significant business impacts. Out of the discussions on the business case emerged one comforting fact in particular – the requirement for remote access was a temporary one. So an agreed upon date by which the access would be closed was arranged at the outset (although major tech refresh projects being what they are, this initially agreed date did not prove to be reliable – but more on this later). With the business case approved and endorsed, I then needed to carry out a risk assessment. I began with detailed discussions with the service provider. To what areas of the system exactly was access required? Via what platform was the service provider proposing to enable access? Which staff needed access? How many? Where would they be located – home or office and geographically? At what times will they need access? Are access requirements for each member of staff the same? To what extent can access be limited to non-production environments? Out of the detailed discussions on the technical platform proposed for the remote access emerged confirmation that a secure accredited channel would be used incorporating: endpoint security including secure build laptops with crypto cards and full disk encryption; and secure connectivity via a SSL VPN using two-factor authentication. Access Control based on role would be applied, and least privilege enforced with system hardening and device lockdown applied to restrict activity to the business need. Crucially, the platform had also previously been subject to approved penetration testing and compliance checks. While the technical security measures therefore seemed to be well covered, I then turned to the procedural measures required to help manages any new risks. A particular area that required attention was the fact that no Remote Access Policy or Security Operating Procedures (SyOps) for Remote Access were available. The Service Provider agreed to work with me to draw up these documents, which would be issued to all staff using the remote access facility. The staff would then be required to familiarize themselves with the content and sign a document confirming that they would be complying. The Remote Access Policy clearly communicated the responsibilities of the users in relation to operating the remote access facility securely and safeguarding the allocated mobile devices and cryptocards. It also clearly stated which working environments would be authorized for the remote access (e.g. approved areas of the service provider’s premises and home working – subject to home working procedures) and those which were not (e.g. outside the country and public areas ‘on the move’ and ‘at rest’). In addition, the policy also made the remote users aware that their activity was to be monitored as part of the required security arrangements. The policy was supported by remote access security operating procedures which were drawn up to reflect relevant standards and best practice and covered areas such as patching and anti-virus software for the mobile devices, authentication, password management, least privilege, system hardening, and incident reporting. Other measures that I arranged to be put in place included: the “ratcheting up” of auditing and monitoring and the provision of regular reports specifically covering the remote access usage; the number of users permitted would be kept to the absolute minimum and this would be kept under review; and that only staff with current security clearance would be included. On this last point, it is worth seeking copies of clearance certificates, as you may find when you request these that some staff initially reported as being currently cleared are actually “in the process of being cleared”. A further measure that I also requested by way of additional mitigation of risk was that the service provider would carry out regular internal vulnerability scanning across the entire network and provide reports on this for the duration of the remote access period. With agreement that all of the measures referred to above would be implemented, I was content, as IT Security Manager, to provide approval for the temporary remote access on this basis. As mentioned earlier, while an initial end-date was agreed upon, slippage with the tech refresh project – not wholly unexpectedly – led to a request for a 2-month extension to the temporary requirement. When I received this request, I initiated a review of the measures agreed upon prior to the initial approval to confirm that these were all operating effectively. In particular, I requested that the Service Provider carry out a review of the number of staff requiring access. As a result of this review – which confirmed a more limited requirement for remote access during the extended period – the number of users was reduced, and the facility for remote access was removed for some 25% of the staff. It was also agreed that the 2-month extension would be the absolute end date for the temporary arrangements. So to summarize: Prohibiting any remote access provides a level of assurance in respect to system security risk mitigation by limiting vectors of attack. But where the business need for remote access arises, this can be managed by the implementation of appropriate countermeasures to minimize any additional risk (as ever, of course, risk can never be fully eradicated). If a business case is put forward, challenge it – if necessary. Ensure it is robust and endorsed by senior management. Can the introduction of remote access be time-bound? If so, agree a firm end-date. Ensure that a secure platform with adequate end-point and connectivity security is used. Keep the number of users to the absolute minimum number of security cleared staff, and keep this number under review. Have the remote users sign a Remote Access Policy and SyOPs and check the specific auditing and monitory reports which will help to provide assurance that they are complying. And finally consider any additional measures that can be introduced in your particular environment, such as regular internal vulnerability scanning. Good luck.
