Applying the CPNI Top 20 Critical Security Controls in a University Environment

Transcription

1 IT Services Applying the CPNI Top 20 Critical Security Controls in a University Environment RUGIT IT Security Group October Introduction Universities UK (UUK) has published a policy briefing on protecting Universities from cyber threats 1. Amongst the guidance is a recommendation that universities apply the 20 controls for effective cyber defence as set out on the Centre for the Protection of National Infrastructure website. The Centre for the Protection of National Infrastructure (CPNI) controls are intended primarily for organisations in the communications, emergency services, energy, financial services, food, government, heath, transport and water service sectors that make up the national infrastructure. As such they may not be a completely natural fit for universities or take account of the particular challenges of the academic sector. The Russell Universities Group of IT Directors (RUGIT) has therefore asked members of the RUGIT IT Security Group 2 to review the CPNI controls and report back on their applicability in an academic environment. After some initial discussion, it was decided that the IT Security Group would answer the following questions for each control. 1. control appropriate for use in a university environment? 2. Has this type of control already been implemented (either fully or partially) at Russell Group Universities? 3. Where is the most appropriate place to implement the control? 4. Is there likely to be a budgetary impact from implementing this control? 5. Are there any university specific issues that need to be considered when applying or implementing the control? 1 Cyber security: Protecting Universities from the cyber threat, July Comprised of information security, IT security, risk and IT governance managers of the Russell Group Universities Page 1 of 18

2 Initial findings from this review were presented to RUGIT and representatives of CPNI in April This report provided further detail on the review outcomes and the RUGIT IT Security Group recommendations for applying the controls. 2. General Challenges to Implementation in a University Environment Before considering each individual control, it is best to address some general challenges that universities may face when adopting the controls IT Governance The UUK briefing policy highlights that cyber security risk should be a university level strategic risk management issue rather than an IT issue. IT departments may need to ensure that this distinction is understood at university management level and that appropriate university management backed IT governance policies are in place before attempting to implement some of the controls Risk Management In order to ensure that the controls are applied appropriately, it is important that information security risk management activities are tied into university level strategic risk management processes. Failure to link the two effectively may lead to gaps in risk management or controls being implemented in a way that does not fit the overall business need Open Networks Universities are traditionally very open organisations and campus networks reflect this openness to encourage collaboration between academics, students and research partners and facilitate outreach activities with the general public. Campus networks are also different in the sense that most of a university s customers (students) sit on the inside of the enterprise network not the outside. The boundaries between the enterprise network and the customer-facing network are therefore less clear. Given this, one of the key recommendations when adopting the CPNI controls is that universities start from the premise that their entire network is essentially an untrusted zone within which sits critical elements (data centres, HPC clusters, lab networks, individual servers etc.) containing essential services and sensitive data that are at risk and in need of additional protection. Adopting this view of the network allows many of the controls to be seen in the right context they are sensible to do when applied only to the at risk areas and not the whole network. Page 2 of 18

3 2.4. University Structure Another challenge to adoption of the CPNI controls is that not all universities are structured the same way and so all the controls will not fit all university networks equally well. Collegiate universities may have very devolved governance and IT functions and a great deal of autonomy at the college level which makes implementation of the controls more difficult if not impossible. Centralized universities may be able to manage the governance and policy issues associated with some controls more easily but still struggle to implement them quickly if IT functions and responsibilities are devolved to schools rather than provided from a professional services function at the core. Given this, the recommendations for adoption of the CPNI controls are generally broad-based rather than specific and institutions should tailor them to their own particular circumstances. 3. Format of the Review and Presentation of Findings The review of the CPNI controls by the RUGIT IT Security Group was conducted through an initial workshop and follow-up discussion via the group s private mailing list. Representatives from 17 of the 24 Russell Group Universities took part along with JANET s Chief Regulatory Advisor. Each control was discussed and votes taken to summarise the collective view on the questions described in the introduction: 1. control appropriate for use in a university environment? 2. Has this type of control already been implemented (either fully or partially) at Russell Group Universities? 3. Where is the most appropriate place to implement the control? 4. Is there likely to be a budgetary impact from implementing this control? 5. Are there any university specific issues that need to be considered when applying or implementing the control? A common format has been adopted to summarise the response to each of the twenty controls. The first four questions described in the introduction are answered using a table like the one below. Page 3 of 18

4 For each of the question, the answers are summarised using the following key: Symbol Meaning 80% of review participants agreed 50% of review participants agreed Less than 50% of review participants agreed Please note that for question 2, answers to the questions already in reflect the number of participants that indicated that they had fully or partially implemented the particular control. A green tick therefore represents that 80%+ of participants have fully or partially implemented the control. Full answers for all twenty controls can be found in the next section. 4. Control Implementation Recommendations 4.1. Control 1: Inventory of authorised and unauthorised devices Reduce the ability of attackers to find and exploit unauthorised and unprotected systems. Use active monitoring and configuration management to maintain an up-to-date inventory of devices connected to the enterprise network, including servers, workstations, laptops, mobile, and remote devices. Respondents agreed that this control was desirable for at risk areas of the network only. If applied across the whole campus network it could be difficult to implement or detrimental to IT service provision by preventing staff, students and visitors from using personal devices. There is a general expectation from students arriving on campus that they will be able to connect their own laptops, tablets and mobile devices to Page 4 of 18

5 the campus network for use during their studies. Implementing solutions that prevent this can have a negative impact on the perception of IT provision which needs to be considered when planning this type of control. It was also noted that there are a range of technologies in this space with different models for authorising and inventorying devices. Some universities currently only inventory servers which may limit what can be achieved Control 2: Inventory of authorised and unauthorised software Identify vulnerable or malicious software to mitigate or root out attacks. Devise a list of authorised software for each type of system, and deploy tools to track software installed (including type, version, and patches) and monitor for unauthorised or unnecessary software. There are similar issues to those described for control 1. Personal devices on the campus network imply a wide range of personal software is also present. This can be difficult to manage via a list of authorised software. It is therefore best applied for at risk areas only where more sensitive data or IT services are present and higher levels of security and access control are required. Given the wide range of third party, open source and legacy applications used for research and the number of applications developed in-house, white listing across the whole estate would be detrimental for research activity. Research software is often very specialist and unlikely to be correctly classified by tracking tools developed primarily for detecting and classifying commercial software. Institutions may find it harder to comply with the authorised software control than the authorised hardware control. Information security managers did note that maintaining an inventory of vulnerabilities across campus might be useful for risk and mitigation planning Control 3: Secure configurations for hardware and software Prevent attackers from exploiting services and settings that allow easy access through networks and browsers. Build a secure image that is used for all new Page 5 of 18

6 systems deployed to the enterprise, host these standard images on secure storage servers, regularly validate and update these configurations, and track system images in a configuration management system. Again, similar issues around the use of personal devices raised for controls 1 & 2, mean that this control may be more appropriate for at risk areas only. Some universities do use standard images for the parts of their estate that can be commoditised (e.g. laboratory PCs, library PCs, PCs and laptops for administrative staff). Teaching, research and administration functions often have their own profiles and this can mean more effort is required to manage this function than might be the case in a corporate environment. Hardware and software needs for teaching and learning across different faculties may make standard images difficult to maintain across the organisation. Science, Engineering and Medical schools tend to require more specialist hardware and software and their profiles can be substantially different than those required for Arts and Social Sciences schools. Any solutions to manage hardware and software configurations must be flexible enough to handle these considerations. Builds of standard hardware and software are more easily achieved when supported by a central procurement process through which all IT purchases must be made. Institutions with devolved procurement may face additional challenges in meeting this control. At some institutions research grant holders are still able to make IT hardware and software purchases themselves without reference to the IT department Control 4: Continuous vulnerability assessment and remediation Proactively identify and repair software vulnerabilities reported by security researchers or vendors. Regularly run automated vulnerability scanning tools against all systems and quickly remediate any vulnerabilities - with critical problems fixed within 48 hours. Page 6 of 18

7 There is significant support for this type of control from information security managers however, the requirement to fix within 48 hours is seen as unworkable (or hugely expensive) in many universities, particularly during extended Easter and Christmas closures when staffing levels are lower. It is recommended that decisions on response times be risk-based with the fix time determined by the implied risk to the campus so that resources can be focused intelligently (e.g. quicker response times for critical vulnerabilities with exploits in the wild than for theoretical and unproven vulnerabilities or non-critical vulnerabilities). Some information security managers use other compensating controls to manage risk and mitigate against a slow update or patching cycle (e.g. firewall blocking, proxies or anti-virus software). It was noted that vulnerability scanning is usually the easier part of the process. Remediation work is more staff intensive (and therefore higher cost). While operating system level patching can often be automated, application level and service level remediation is often a more manual process, especially for servers and critical IT services. Time for patching and maintenance needs to be planned into regular software development and service development activities. Remediation is also often a business issue rather than an IT issue and service down time to fix vulnerabilities may need to be negotiated with the relevant business owners. There was no clear consensus on whether it is best to apply this control to the whole network (and understand the overall risk) or to only at risk areas (and thus be more likely to concentrate limited remediation resources on fixing critical systems) Control 5: Malware defences Block malicious code from tampering with system settings or contents, capturing sensitive data, or spreading. Use automated anti-virus and antispyware software to continuously monitor and protect workstations, servers, and mobile devices. Automatically update such anti-malware tools on all machines on a daily basis. Prevent systems from using auto-run programs to access removable media. Page 7 of 18

8 This control is generally in place at Russell Group institutions for workstations and servers (but see the comments on server deployment below). Malware defences for mobile devices and tablets are less well established but becoming an issue that IT departments need to focus on as the risk of attack from these devices increases. Care needs to be taken when deploying on servers and research equipment with high data throughput where performance is critical. Antivirus scanning of files may need to be limited in such environments. It should also be noted that specialist or expensive research equipment sometimes comes with a maintenance agreement that prevents patching or deploying anti-virus software without explicit permission from the vendor. Separate arrangements may be required to protect these systems. The recommendation to deploy only in at risk areas is primarily down to the difficultly of enforcing the use of anti-virus software on personal devices. While information security managers would recommend that staff, students and guests use anti-virus software on their personal devices, it is often not possible to enforce this behaviour. Institutions should however promote free versions of anti-virus software provided by reputable security companies wherever possible to encourage take up Control 6: Application software security Scan for, discover, and remediate vulnerabilities in web-based and other application software. Carefully test internally developed and third-party application software for security flaws, including coding errors and malware. Deploy web application firewalls that inspect all traffic, and explicitly check for errors in all user input (including by size and data type). Page 8 of 18

9 Some institutions have deployed application level firewalls; however they are not yet widespread. Awareness of secure coding practices is increasing. Even so, the quality of third party and internally developed applications still needs improving and IT departments must ensure they have coding practice policies in place which hold developers to relevant standards 3. Development work for research projects or departmental web sites is often performed by academics rather than professional IT staff. Security is often an afterthought rather than a priority. This is a concern given the results are often open to the Internet to publicise the research group or departmental activity. Educating academics on secure coding practices is likely to be a big challenge for many institutions. Where possible policies should be put in place to hold academic developers to the same coding standards as IT professionals. Academic developers should also be targets of information security awareness programmes (control 9). ary impact is likely to be led by people, policy and process costs rather than technology Control 7: Wireless device control Protect the security perimeter against unauthorised wireless access. Allow wireless devices to connect to the network only if they match an authorised configuration and security profile and have a documented owner and defined business need. Ensure that all wireless access points are manageable using enterprise management tools. Configure scanning tools to detect wireless access points. The need to support personal devices and to facilitate collaboration with visiting academics, commercial partners and suppliers makes the first part of this control difficult to implement in a university environment. The requirement to limit access by authorised configuration and business need is therefore seen as undesirable on campus wireless networks and is generally addressed by treating wireless as untrusted and 3 Such as OWASP for web application development Page 9 of 18

10 instead managing connectivity between untrusted and at risk parts of the network. Access point management and scanning for unauthorised access points is generally enforced Control 8: Data recovery capability Minimise the damage from an attack: Implement a trustworthy plan for removing all traces of an attack. Automatically back up all information required to fully restore each system, including the operating system, application software, and data. Back up all systems at least weekly; back up sensitive systems more often. Regularly test the restoration process. All participating Russell Group institutions have business continuity and disaster recovery processes in place. Coverage varies but critical systems and services are generally covered. Data backup and recovery facilities are desirable across the whole organisation however costs need to be weighed for enterprise storage systems given the enormous quantity of data generated by some research activities. Enterprise data storage and backup services can be perceived as costly by some academics when compared to personal and home backup solutions. IT departments need to ensure that the benefits are made clear and that high value assets are not at risk from inappropriate local solutions. Given the cost-benefit issues described above, IT departments need to avoid recharging for enterprise storage costs if possible to avoid creating unhelpful incentives for researcher to go out and buy their own (inappropriate) backup solutions Control 9: Security skills assessment and appropriate training to fill gaps Find knowledge gaps, and fill them with exercises and training. Develop a Security Skills Assessment program, map training against the skills required for Page 10 of 18

11 each job, and use the results to allocate resources effectively to improve security practices. Given the wide range of usage profiles and skills across the organisation, this is currently an area of weakness for many that has been difficult to address. Increasing numbers of attacks based on social engineering make progress in this area desirable. Awareness training needs to be relevant to the level of risk and should be matched to roles where possible. Students should be included in awareness programmes. IT departments do need to take into account the academic cycle (with roughly a third of the student body replaced each new academic year) and devise student awareness programmes accordingly Control 10: Secure configurations for network devices Preclude electronic holes from forming at connection points with the Internet, other organisations, and internal network segments: Compare firewall, router, and switch configurations against standards for each type of network device. Ensure that any deviations from the standard configurations are documented and approved and that any temporary deviations are undone when the business need abates. There is general agreement that this control is desirable across the whole organisation. Page 11 of 18

12 It is generally in place at all participating Russell Group institutions Control 11: Limitation and control of network ports, protocols, and services Allow remote access only to legitimate users and services. Apply host-based firewalls and port-filtering and scanning tools to block traffic that is not explicitly allowed. Properly configure web servers, mail servers, file and print services, and domain name system (DNS) servers to limit remote access. Disable automatic installation of unnecessary software components. Move servers inside the firewall unless remote access is required for business purposes. Desirable across the whole network and partially implemented in most institutions. IT departments may need to review resourcing to achieve full compliance against this control given the scale of enterprise services provided. Institutional information security policies may need to be updated to make these controls mandatory across the whole estate Control 12: Controlled use of administrative privileges Protect and validate administrative accounts on desktops, laptops, and servers to prevent two common types of attack: (1) enticing users to open a malicious , attachment, or file, or to visit a malicious website; and (2) cracking an administrative password and thereby gaining access to a target machine. Use robust passwords that follow known standards. Page 12 of 18

13 Although there is general recognition that administrative accounts need to be protected where possible, this may be difficult in some institutions and a range of different techniques are used to achieve this control. Institutions with IT management devolved to schools or departments may need to be more flexible to achieve their aims than those with strong, central IT management functions. Some institutions prefer to offer users admin accounts on managed desktops to prevent them from introducing unmanaged computers to the network. Researchers often want to manage their own equipment, and depending on procurement policies, may be able to purchase and install systems independent of the IT department. Strategies to mitigate or manage the risk to research data need to be considered if this is an issue. Password policies may be compromised by legacy systems (especially expensive and therefore long lifespan research equipment) with older operating systems or applications that don t support password enforcement or long passwords. Auditor s insistence on regular password changes (sometimes 30 days for admin accounts and 90 days for other accounts) are seen as tick box solutions to complex problems and unhelpful and should be challenged when a better mix of password security options can be offered and enforced Control 13: Boundary defence Control the flow of traffic through network borders, and police content by looking for attacks and evidence of compromised machines. Establish multilayered boundary defences by relying on firewalls, proxies, demilitarised zone (DMZ) perimeter networks, and other network-based tools. Filter inbound and outbound traffic, including through business partner networks ( extranets ). This is desirable but needs to be carefully planned and implemented so that blocking does not unduly inhibit academic freedom or hinder research work. Web content filtering for example can be contentious. Web sites considered undesirable by information security managers may be Page 13 of 18

14 considered essential by researchers. Information security policies should clearly explain and be able to justify what categories of web content are blocked. Many universities have embraced social media to engage with students, prospective students and the general public through services they are familiar with and use regularly. Therefore whilst these services might normally be blocked by corporate IT departments, they often need to be factored into boundary defence policies at academic institutions. It is noted that proxies and gateway devices can have difficulties processing the wide range of traffic on campus networks. This is especially the case with home grown research applications and lower quality open source applications that do not fully implement Internet standards Control 14: Maintenance, monitoring, and analysis of security audit logs Use detailed logs to identify and uncover the details of an attack, including the location, malicious software deployed, and activity on victim machines. Generate standardised logs for each hardware device and the software installed on it, including date, time stamp, source addresses, destination addresses, and other information about each packet and/or transaction. Store logs on dedicated servers, and run biweekly reports to identify and document anomalies. Most Russell Group universities have some logging in place but would like to extend this capability to more key systems. The scale of the enterprise makes this resource intensive. Larger institutions are generating millions of logs and hundreds of thousands of events per day. Extracting the most meaningful events can therefore be difficult even when deployed commercial log managers or security event and incident management (SEIM) solutions. Information security staff may need to work with colleagues across the IT department and business systems owners to identify the most critical events to track and report on Control 15: Controlled access based on the need-to-know Page 14 of 18

15 Prevent attackers from gaining access to highly sensitive data. Carefully identify and separate critical data from information that is readily available to internal network users. Establish a multilevel data classification scheme based on the impact of any data exposure, and ensure that only authenticated users have access to non-public data and files. This is the activity that will define the at risk areas used for most other controls. It is recommended that high level risk analysis be performed at the logical network level, service level or similar before attempting analysis at the data level or introducing a data classification schema. Some Russell Group universities have introduced data classification schema. Implementation will require participation by data owners and business process owners and so can be very resource intensive. University level management will need to be persuaded of the benefits of this control and sign-off on the resource commitment required across the organisation to achieve it. Appropriate institutional data governance or records management policies will also be required before proceeding Control 16: Account monitoring and control Prevent attackers from impersonating legitimate users. Review all system accounts and disable any that are not associated with a business process and owner. Immediately revoke system access for terminated employees or contractors. Disable dormant accounts and encrypt and isolate any files associated with such accounts. Use robust passwords that follow known standards. Page 15 of 18

16 Most institutions have some form of identity and access management system in place however, often only centrally managed IT services and equipment are linked and authenticate users through it. Systems in schools or departments may run with local user accounts not linked to the central IAM service and not following IAM policy rules. Treating the campus network as untrusted can help mitigate the risk of local account creation as long as access to all at risk areas or services are managed through the central IAM service and local accounts are prevented from accessing critical services or data. While account provisioning for staff and students is generally well managed, there is often a grace period for staff and students leaving the organisation when accounts remain open. If ending the grace period is not automated or formally managed, this can be a problem. Emeritus staff are the extreme case as they can often retain user accounts for many years. Accounts for users more loosely tied to the university can also be a problem. Some academics are part-time, employed by other organisations or granted academic status based on their expertise elsewhere (e.g. NHS staff associated with Medical Schools). Managing the creation and closure of these accounts can be challenging Control 17: Data loss prevention Stop unauthorised transfer of sensitive data through network attacks and physical theft. Scrutinise the movement of data across network boundaries, both electronically and physically, to minimise the exposure to attackers. Monitor people, processes, and systems, using a centralised management framework. This is desirable for at risk areas. This control is partially met in most institutions with firewalls and encryption used where possible to prevent data leaking out of the organisation unintentionally. Monitoring of data transfers across network boundaries is seen as very difficult because of the amount of data being moved. Automated DLP tools and gateways are only useful if the data at risk can be identified easily. As research data is often more unstructured than corporate data, default rules provided by DLP systems are not helpful. Full DLP is unlikely to be possible until full data classification has been undertaken (control 15). Page 16 of 18

17 4.18. Control 18: Incident response capability Protect the organisation s reputation, as well as its information. Develop an incident response plan with clearly delineated roles and responsibilities for quickly discovering an attack and then effectively containing the damage, eradicating the attacker s presence, and restoring the integrity of the network and systems. Most Russell Group universities have implemented or partially implemented this control. Levels of formality vary and in some cases there is a well understood and repeatable process but it is not formally documented Control 19: Secure network engineering Keep poor network design from enabling attackers. Use a robust, secure network engineering process to prevent security controls from being circumvented. Deploy network architecture with at least three tiers: DMZ, middleware, private network. Allow rapid deployment of new access controls to quickly deflect attacks. This type of control is recognised as a worthy goal by most institutions. Universities were amongst the earliest adopters of networking technologies and many campus networks have evolved over many years. Reengineering to meet current best practice requires significant resource and downtime and so is a long term objective rather than a short term one. Page 17 of 18

18 The 3 tier model recommended is probably too simplistic for most Universities given the issues with personal devices, collaborative use of wireless and local IT provision mentioned previously Control 20: Penetration tests and red team exercises Use simulated attacks to improve organisational readiness. Conduct regular internal and external penetration tests that mimic an attack to identify vulnerabilities and gauge the potential damage. Use periodic red team exercises all out attempts to gain access to critical data and systems to test existing defences and response capabilities. This is seen as desirable in at risk areas. Regular testing depends on availability of resources and so resourcing levels need to be agreed with IT management and planned into departmental activity. As mentioned previously, mitigation is significantly more resource intensive that penetration testing and should be resourced appropriately relative to the amount of testing done. Page 18 of 18