The Operator Console

Transcript

THE OPERATOR CONSOLE A Basic Guide to Critical Infrastructure Protection January 2014 TABLE OF CONTENTS AIMS OF THIS GUIDE ......................................................................................................................3 THE USER ........................................................................................................................................4 TYPES OF THREAT ......................................................................................................................4 APTs (Advanced Persistent Threats)...........................................................................................4 Social engineering .......................................................................................................................5 Spear phishing attacks .............................................................................................................5 Infections through websites ......................................................................................................5 Physical equipment .....................................................................................................................6 Vulnerabilities of equipment and zero-day attacks .......................................................................6 THE OPERATOR’S CONSOLE ........................................................................................................7 CONTROLS SPECIFIC TO THE CONSOLE ..................................................................................7 Secure configuration for hardware and software .........................................................................7 Setting up anti-malware measures ..............................................................................................8 Capacity for data recovery...........................................................................................................8 Controlled use of administrator privileges ....................................................................................8 Access based on “need to know” .................................................................................................8 OTHER TYPES OF CONTROL ......................................................................................................9 Use of HIDS ................................................................................................................................9 Honeytokens .............................................................................................................................10 IOC indicators ...........................................................................................................................11 EMET and CrystalAEP ..............................................................................................................13 EMET .....................................................................................................................................13 CrystalAEP ................................................................................................................................16 Security reputation of the software and/or hardware supplier ....................................................17 LEGACY ENVIRONMENTS .........................................................................................................18 MOBILE EQUIPMENT .................................................................................................................19 CONCLUSIONS ..............................................................................................................................20 Authors Co-ordination Jesús Díaz Vico Deepak Daswani Daswani Daniel Fírvida Pereira Elena García Díez Marco Antonio Lozano Merino THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 2 1 AIMS OF THIS GUIDE This basic guide for the protection of critical infrastructures, intended to Operator Console is intended to cover the essential aspects of security relating to the user’s or Supervisory Control And Data Acquisition (SCADA) operator’s console. For this purpose, it refers to the threats that may have major impact on a technological infrastructure of this type. In most instances, it offers high-level applicable solutions and alternatives. The individual characteristics, needs and particular technologies of certain operator consoles may limit direct application of some of the measures envisaged in this guide. Applicability to specific environments must be assessed proportionally to the technological factors and technical properties of the systems to be protected, or the business model of the enterprise concerned. In this way, the guide must be seen as a series of desirable, but not always strictly necessary, measures for improving the security of the operator console of a critical infrastructure. Moreover, as the guide is aimed at protecting the operator’s console of such crucial infrastructures, which inherently require a high level of security, it will be assumed that this equipment is covered by strict corporate security policies. Therefore, basic security measures such as the use of robust passwords, are taken for granted. Note that some fragments of this document are based on the content of the report “Detección de APTs” jointly created by INTECO and CSIRT-CV, available at the websites of INTECO-CERT 1 and CSIRT-CV2. Thus, the mentioned report may help to correctly understand what is herein stated. This technical publication is framed within the specific actions of the CERT de Seguridad e Industria line of protection of critical infrastructures, as defined in the agreement subscribed in October 2012 by the Secretaría de Estado de Seguridad (SES) of the Ministerio del Interior and the Secretaría de Estado de Telecomunicaciones para la Sociedad de la Información (SETSI) of the Ministerio de Industria, Energía y Turismo, for an effective cooperation in the subject of cyber-security between CNPIC, FCSE and INTECO. 1 2 http://cert.inteco.es/extfrontinteco/img/File/intecocert/EstudiosInformes/deteccion_apt.pdf http://www.csirtcv.gva.es/sites/all/files/downloads/Detecci%C3%B3n_APT.pdf THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 3 2 THE USER A large part of the incidents that occur in information technology systems are triggered by users themselves. In the case of SCADA or industrial environments, despite being systems of considerable criticality provided with additional controls, the same may occur. For this reason, one of the key elements that will be covered in this guide will be actions focused on technical aspects and good practices when interacting with elements forming part of this environment, like Human Machine Interfaces (HMI). Offering users information relating to the various types of threat that exist and the ways of mitigating them is one of the key aspects when confronting the risks that threaten computer systems. TYPES OF THREAT SCADA environments, despite having devices specifically developed to carry out specialized tasks, in general suffer from the same security problems as other technological architectures, mainly because they share technologies like operating systems or Internet devices. Moreover, being managed and controlled by humans, it is possible to speak of an infrastructure subject to a multitude of security problems, not to mention the vulnerabilities inherent in certain devices, such as PLCs. The following points will explain the threats that are likely to have the greatest impact within a SCADA architecture. APTS (ADVANCED PERSISTENT THREATS) Currently, cyber-attacks and systems failures in critical infrastructures are among the Top Five global risks, according to the recent report ‘Global Risks 2012’ 3 from the series published each year by the World Economic Forum (WEF) 4, reflecting the present-day interconnection between geo-political, environmental, social, economic and technological risks. Among technological risks, cyber-attacks occupy a pre-eminent position as the principal concern, as they have major impacts and a high degree of probability of occurrence. Over the last four years, the number of cybernetic threats has multiplied exponentially, as well as undergoing a change in nature. From known threats, scarce and exceptional, there has been a shift to threats of great sophistication, persistent, and with very specific objectives, giving rise to a new category of threats in the world of cyber-crime, Advanced Persistent Threats, hereinafter APT or APTs. APTs are characterized by being real and sophisticated threats which, whilst not always of great technical complexity, involve highly premeditated and persistent actions. They are very effective against the countermeasures set up in the system or systems targeted. They are of a particularly silent nature and their aspirations are extensive. Those affected are rarely conscious that they are the target of an attack and are unaware of its origin, scope or authorship. Once a single target has been picked out, the cyber-criminals begin an offensive campaign in which the amount of time invested is of no consequence. 3 4 http://www3.weforum.org/docs/WEF_GlobalRisks_Report_2012.pdf http://www.weforum.org/ THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 4 The attackers do not hope to obtain any short-term benefit (as might be sought by other types of mass attack), but rather they prefer to remain unnoticed, while striving constantly until they achieve their objectives. Among these, the aims may be of varying types: economic (industrial espionage), military (searching for weaknesses, revealing secret information), technical (gaining access to credentials or source code) or political (destabilizing, disorganizing or weakening diplomatic missions), affecting sectors as diverse but as critical as government, finance, technology, research centres and the like. SOCIAL ENGINEERING At the start of this section, it was commented that the human factor (the user) is one of the most critical elements when a security plan is being put in place. Consequently, social engineering is without a doubt the most vulnerable point for users. The term social engineering technique is used for any method in which the attacker attempts to achieve an objective through deceiving or manipulating people. This may involve gaining access to privileged information, getting a user to visit a particular hyperlink or to open a document sent by email, or encouraging a user to allow a stranger to enter an organization’s installations, for instance. In brief, causing victims to be incautious enough to carry out actions which may harm them or the organizations for which they work. Through this type of technique many other approaches can be derived that make use of varying technologies like e-mail, browsing and others to give rise to differing routes for infection. SPEAR PHISHING ATTACKS This technique consists of using social engineering to trick a user by means of an email, the objective being specific users or companies, rather than the indiscriminate targets of normal phishing. Perhaps the most representative example would be sending emails with a malicious URL or attachment and with a striking message that will incite the victims to open it. These emails usually include PDF, DOC, XLS or similar attachments, containing malicious code that will attempt to exploit some vulnerability so as to be able to execute harmful commands within the equipment. In the worst cases, it is possible to take advantage of zero-day attacks, which offer a greater chance of success in gaining access to the machine, even if victims have correctly updated protective software. Spear Phishing Attacks are among the most often used methods as a route for infections. INFECTIONS THROUGH WEBSITES given website that has previously been compromised. In general terms, the operation is as follows: attackers seek out a vulnerable website and insert a malicious script into its HTML code. Victims visit compromised pages and the website returns the page consulted together with malicious code, which usually forces victims’ browsers to make fresh requests to other web servers also controlled by the attacker. From these malicious web servers, the attacker will attempt to exploit some vulnerability of the user’s browser, downloading malware and infecting user equipment in the case of a successful attack. It is common to find that malicious code is introduced by means of an iframe (in-line frame) in the compromised website that is visited by the user. This iframe opens in parallel, in a way practically transparent to users, a second website, which is the one that will trigger the downloading and execution of malware that will infect the user. Another option is for the compromised website to redirect to a malicious site. When using this technique, an attacker infects a user merely by getting him/her to visit a 5 http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-spear-phishing-email-mostfavored-apt-attack-bait.pdf THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 5 PHYSICAL EQUIPMENT Another method that could be employed to introduce malware into a firm or organization is the use of physical equipment. It suffices with connecting to the network infected USBs, CDs, DVDs, memory cards or IT equipment to introduce the malware into the organization targeted. As an example, in the case of the attacks directed through the Stuxnet 6 worm, the initial infection was achieved by means of an infected USB memory (some sources indicate that it was introduced by a double agent who was working for Israel, using a USB pendrive to infect the machines in the nuclear plant at Natanz). In a hypothetical scenario, the attacker might use techniques of social engineering or other kinds of trickery to circumvent the physical security arrangements of the installations of the organization being targeted and gain access with an infected USB to a piece of equipment connected to the corporate network. Another possible attack scenario might be for attackers to take on the identity of a customer or to pass themselves off as people interested in the organization being targeted, then using a supposed marketing campaign to give away infected USB devices, memory cards, CDs or DVDs, smart phones, tablets, laptops or any type of device, or even software, to employees. It is possible for an attacker to provide victims with malicious pirate software packaged like the packaging of the original manufacturer, so that the target users do not notice the deceit. There is also the typical trick of leaving an apparently 6 http://es.wikipedia.org/wiki/Stuxnet mislaid USB drive lying around with a label suggesting it contains private information. It is highly likely that the curiosity of the user finding such a “lost” USB drive will lead to it being connected to a piece of equipment, infecting it. It is worth to emphasize that humans are curious by nature and many social engineering techniques work on this basis. VULNERABILITIES OF EQUIPMENT AND ZERO-DAY ATTACKS Although they have been briefly mentioned in earlier sections, there are other threats that are hard to counter. These are failures that are embedded in specific pieces of equipment, for example programmable logic controllers (PLCs), which form a part of the architecture of a SCADA system or make up the elements controlling some critical infrastructure. At first, perhaps, these vulnerabilities did not pose any problem, since systems were not connected to the Internet. However, now that infrastructures have generally become connected, the problems have been revealed and a good number of investigators have uncovered a multitude of security failures related to this equipment. Luckily, when one of these failures has been reported to the manufacturers, in many cases they have released security patches to correct the fault and on occasion they have even sent out new equipment with the problems fixed. It is very important to be aware of this problem, since it is mostly hard, if not impossible, to determine whether the equipment composing an architecture has such vulnerabilities or not. If this is the case, the most advisable course is to act as soon as possible to try to mitigate the threat implied by the security failure. THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 6 3 THE OPERATOR’S CONSOLE One of the key elements in industrial environments is the control of processes. This control is exercised through interfaces that provide to the operator supervising it real-time information about the progress of the process. This information is shown through purposebuilt control panels (so-called operator prompts) or on computer screens. In the first case it is relatively complicated to establish security measures, because the specific piece of equipment, being manufactured for a particular need, would have to be analysed in order to set up controls. In the second case, as it is a general-purpose computer (PC or server), it would be a simpler matter to specify concrete measures to guarantee its security. Throughout this section descriptions of essential features will be given for establishing a minimum set of controls to guarantee security in relation to operator console based on PCs or servers. There will also be descriptions of various tools and techniques that allow the identification and warding off of possible attacks. CONTROLS SPECIFIC TO THE CONSOLE The security needs of organizations and businesses are not homogeneous in nature. They must be adapted as a function of the business or operational strategy in place. Nonetheless, there should always be a series of controls that may be applied so as to guarantee acceptable security levels. SECURE CONFIGURATION FOR HARDWARE AND SOFTWARE Although many enterprises have extremely heterogeneous software and hardware environments, it is advisable to ensure the secure installation of applications and operating systems, by keeping the following recommendations in mind:  Eliminate unnecessary accounts.  De-activate services that are not going to be used, together with associated positions.  Limit manual and automatic execution of programs.  Implement updating policies for software (operating systems, applications and firmware) by using security patches within 48 hours at most after they are published by manufacturers.  Create system images (snapshots) including security configurations to allow rapid restoration in the case of any incident. These snapshots should be stored in an off-line device, to avoid any risk of compromise.  Carry out any remote administrative tasks by means of VNC, Telnet, and similar over secure channels (secure sockets layer [SSL], Internet Protocol Security [IPSec], and the like).  Use applications verifying the integrity of system archives in order to avoid alterations.  Use management tools that facilitate administration of systems, like Active Directory in Windows or Puppet in Unix/Linux systems. THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 7 SETTING UP ANTI-MALWARE MEASURES As with any technological architecture made up of PCs and servers, there should be some type of anti-malware protection, both client side and net side. It should be stressed that, while these measures are useful and necessary, they should be seen as no more than just one further security element to be installed, and in no case as a definitive solution. This is principally because most anti-malware solutions are based on signatures or heuristics that can do nothing against certain attacks or vulnerabilities, like zero-day attacks based on hitherto unknown weaknesses, although they can counter already known threats that might reach systems. This drawback is worsened when, in addition, it is not possible to apply anti-malware solutions to certain devices, such as PLCs. In this case intermediate solutions should be applied, implemented at the level of the network (segmentation of the network, use of a Web Application Firewall -WAF-, or others). The essential measures to be taken include:  Deploy anti-malware solutions on all devices in the business that allow this, such as PCs, servers, mobile devices, proxies, and the like, and have scheduled scans as well as scans triggered by events (for example, the insertion of an external storage device).  Update solutions with the latest files of signatures, versions, and so forth. It should also be checked whether all devices have been updated. CAPACITY FOR DATA RECOVERY System recovery and a return to normal operations as soon as possible should be a key feature of the security strategy of any organization. On this subject, the capacity to recover data is an essential feature, which can be achieved with the following recommendations:  Establish a policy for security copies on the basis of the criticality of the systems for which copies are being made. In any case, a copy should be taken each week at the very least and the data should be encrypted.  As far as possible, establish three types of security copy: one for the operating system, another for applications and a third for data. In this way, it will be possible to restore them independently on another system or hardware configuration.  Carry out restoration and copy verification drills to ensure it is possible to restore systems in the case of any crash. CONTROLLED USE OF ADMINISTRATOR PRIVILEGES Administrator privileges should be granted exclusively to authorized users who undertake management and maintenance tasks for the operating systems running on a SCADA architecture. This will avoid conventional users being able to install applications or carry out tasks exclusive to administrators. ACCESS BASED ON “NEED TO KNOW” “If I can’t touch it, I can’t break it” should be the line taken, while respecting criteria of usability that permit the operator’s work to be carried out effectively and efficiently. Thus, users and operators should have access only to those applications and functions of the operating system that are necessary for the activity that they undertake at their workstations. On this point, it is also possible to set up controls of a physical nature, such as a restriction on the use of storage devices like USB drives or DVDs. THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 8 OTHER TYPES OF CONTROL Thus far, the control measures looked at have been based principally on correct configuration of the hardware and software components of the system, together with essential elements like anti-virus packages or preparation for fundamental actions like appropriate backing-up procedures. Now, consideration will be given to other types of control, such as the deployment of intruder detection systems, Honey Tokens or the use of exploit detection tools. USE OF HIDS It is vital to have detection mechanisms on each of the machines in the business or organization, with the aim of detecting anomalies in the operating system itself. These defences are not restricted to anti-virus software (although this is essential), but also to other tools that allow protection, alerts and the generation of events when something unexpected happens. This is where HIDS (Hostbased Intrusion Detection Systems) come into play. HIDS are simply agents installed individually on each piece of equipment, whose function is to monitor the state of the system. To this end, they use a database for the objects that they are supposed to monitor. For each of these objects, the HIDS has a record of its attributes (permissions, dates, MD5 summary and so forth) in a database. When a change occurs in any of these attributes, it generates an event informing that this is the case. To handle all of these agents centrally, a manager is used, whose function is to correlate the events from each of the agents together with the logs of the various network devices (switches, routers, firewalls, and so on). In this way, it has a control point from which to monitor the status of each agent, to configure alerts as a function of the received events and logs, to search for indicators of compromise (IOC), and the like. Figure 1 shows in graphic format an architecture of this type, specifically the Open-Source OSSEC platform. This brings together all the aspects of a HIDS, control of records and SIM/SEM (Security Incident Management/Security Events Management) in a solution using simple, powerful and open source. Figure 1. OSSEC Architecture. Each of the agents is installed on the various machines (independently of the operating system), and sends every event to the OSSEC Server, the central manager. When any kind of anomaly is detected, the administrator is notified, so as to perform the appropriate corrective actions. It is interesting to consider an architecture of this type for adding one more layer of protection to critical systems. In addition, it should be evaluated the desirability of implementing of NAC (Network Access Control) systems to guarantee compliance with certain security policies on each piece of equipment. The use of these security measures combined with correlation of the information should be highly efficient in detecting any possible intrusion into systems. Apart from architectures like OSSEC, it is advisable to use services like Splunk 7, a system of cloud THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 9 logging to send and synchronize logs from multiple devices and applications. This type of solution permits the investigation of all types of security incidents from the logs recorded. To gain an idea of the potential of this kind of service, it is of interest to consult the series of posts “APTish Attack via Metasploit 8” on Sysforensics, which is an in-depth investigation of an intrusion by means of the persistence script (persistence.rb) of Metasploit. HONEYTOKENS The concept of Honey Tokens is by no means new 9. For more than a decade, these systems have been implemented at network and host levels to identify intrusions. Nevertheless, this type of countermeasure seems to be being increasingly adopted by organizations and firms, owing to their fear of possible intrusions in their systems. The aim of a Honey Token is very similar to that of an IDS (Intrusion Detection System), that is, to detect intrusions in systems. However, a different procedure is used. Whilst an IDS is generally based on signatures to detect anomalous patterns, a Honey Token uses a craftier approach. As with any other sort of Honey Pot, the idea of a Honey Token is to create a trap and then wait for an attacker to fall into it, raising an alert about the intrusion. Perhaps the simplest form of Honey Token would be the setting up of a false e-mail address within a domain, so as to identify possible APT campaigns in the form of Phishing Attacks on the organization concerned. Nonetheless, this concept can be used in many contexts:  The setting up of a false web resource: for example, adding to robots.txt an admin entry "Disallowed".  The creation of false entries in a database: for instance, including false credit card numbers so that any access to them will trigger an appropriate event.  Monitoring a port that should not be accessed.  Creating trap executables such that, if they are extracted and executed by an attacker, they send information about the environment of the intruder involved. As may be seen, as in the case of social engineering, the creation of this type of countermeasure depends upon the craftiness and creativity of whoever is responsible for security. As an example, the following script, developed by Antonio Villalón, shows a simple instance of a Honey Token. The idea is to create a file called "dismissals.doc", apparently listing planned dismissals, in a resource shared by Samba, and to use the API inotify to monitor access to it by means of the following instruction: inotifywait -m -e access DESPIDOS.DOC | while read FILE ACTION; do ACTION done In a more detailed fashion: #!/bin/sh MARGEN=60 LASTU=0 LASTT=0 # Action on access function action(){ echo "ACCESS of $USER to $FILE in mode $ACTION" } function buffer(){ if [ $USER -eq $LASTU ]; then DIFF=`expr $TIME \- $LASTT` if [ $DIFF -gt $MARGEN ]; then action fi else action fi LASTU=$USER LASTT=$TIME 7 http://www.splunk.com/ http://sysforensics.org/2012/11/aptish-attack-via-metasploit-part-one-of-four.html 9 http://www.symantec.com/connect/articles/honeytokens-other-honeypot 10 http://software-security.sans.org/blog/2009/06/04/my-top-6-honeytokens/ 11 http://www.securityartwork.es/2009/05/15/honeytokens/ 12 http://linux.die.net/man/2/inotify_add_watch 8 THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 10 } if [ $# -ne 1 ]; then echo "File access detected" echo "USO: $0 file" exit -1 fi inotifywait -m -e access $1|while read FILE ACTION; do USER=`ps -ef|grep $FILE|head -1|awk '{print $1}'` TIME=`date +%s` buffer done If the function action() is replaced with something more elaborate (for instance, sending an event by e-mail, an SMS, SNMP, or similar) the result will be an intruder detection system that will pick up illicit accesses in a system (whenever there is access to the file in question). As commented by Villalón, the use of this kind of trap is particularly attractive, because in exchange for a minimum investment (Honey Tokens can be very simple and their maintenance once installed is virtually nonexistent) information of great value is obtained. It should be kept in mind that one of the main problems of net-based IDS is the rate of false positives that they can generate and the associated cost of processing all the information they produce from day to day. Similarly, more complex systems like Honey Nets are not often set up, other than in environments that are very large and/or especially aware of security topics, because in general the benefits derived from the system do not usually cover the expense of installing and maintaining it. IOC INDICATORS In previous sections mention has been made of IOC or indicators of compromise. This technology, which has enjoyed a great growth in the last few years, consist of using XML Schemas to describe the technical characteristics of a threat by means of the evidence of compromise that it leaves in the compromised equipment. For example, this may be as a function of the processes, registry entries, services, files downloaded, or other activities after infection. Using OpenIOC13, an open-source framework developed by Mandiant, it is possible to describe the behaviour of APTs or malware semantically by means of XML files and to utilize these to seek for signs of infection in a machine, with no need to carry out an exhaustive analysis to identify the type of threat. Figure 2 shows an extract from an IOC framework, developed by AlientVault 14, corresponding to the APT Red October 15. Figure 2. IOC File. With this framework and the aid of IOC Finder (one of the applications of OpenIOC) it is possible to locate indications of Red October in a computer compromised by this malware. 13 http://blog.zeltser.com/post/44795789779/indicators-of-compromise-entering-the-mainstream https://github.com/jaimeblasco/AlienvaultLabs/blob/master/malware_analysis/RedOctober/48290d24-834c-4097abc5-4f22d3bd8f3c.ioc 15 http://www.securelist.com/en/blog/785/The_Red_October_Campaign_An_Advanced_Cyber_Espionage_Network_Targ eting_Diplomatic_and_Government_Agencies 14 THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 11 Let it be supposed, for example, that an organization has been compromised by this APT. After the infection has been located and the type of threat identified, other pieces of equipment within the same VLAN will be tested to check whether they may have also been infected. For this purpose, it will be necessary to execute IOC Finder, as shown in Figure 3, on each of the machines under suspicion. Figure 3. Mandiant IOC Finder (Collect). Through this process (note the parameter collect), IOC Finder copies a collection of data from the dubious equipment (in this case, from unit “g:”) and stores them in a given directory in the form of XML files. These files represent a multitude of attributes corresponding to processes, registry entries, files, and the like, which will subsequently serve as an inspection source to locate any trace of infection, in this case by the APT Red October. Once the data gathering process is over (the process may take hours) all that needs to be done is to execute IOC Finder with the parameter report. For this it will be necessary to specify, on the one hand, the source for the previously generated data and, on the other, the .ioc file or files defining the patterns of infection it is desired to locate, as shown in Figure 4. Figure 4. Mandiant IOC Finder (Report). As may be seen, indicators of compromise represent an efficient and rapid way of identifying and defining advanced threats which otherwise would be very hard to find evidence for and which in some cases would pass unnoticed by AV or HIDS systems. Hence, it is advisable to consider using THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 12 them to analyse equipment that shows strange behaviour, for instance, machines with unusual traffic patterns. For more information about IOC, it is possible to consult the presentation entitled Identifying & Sharing Threat Information 16 by Mandiant or the white paper Using IOC (Indicators of Compromise) in Malware 17 by SANS Institute. EMET AND CRYSTALAEP It has been previously mentioned some of the methods attackers have for breaking into systems through various techniques (social engineering, phishing or spear phishing, and so forth). If, in addition, there is use of encoders, packers or other elements tending to confuse matters, then the detection of this type of threat, for instance by antivirus software, becomes much more complicated. Hence, it is highly recommendable to have specialized tools for the detection of exploits that permit attempts to exploitation processes (for example, the browser) to be picked up that otherwise would be missed by antivirus packages. EMET One of the best known tools for countering this type of attack is EMET (Enhanced Mitigation Experience Toolkit) 18, a tool developed by Microsoft which tries to reduce the likelihood of an attacker executing malicious code through a given program. The utilization of malicious PDF files to compromise equipment through phishing attacks is a clear example of this. The same thing happens with applications like Flash, Java, Firefox, or with Office documents. The use of EMET can be of enormous help in preventing a great number of attacks that try to take advantage of insecure software and weak security configurations in operating systems. Among the benefits offered by EMET are those described below:  Implementation of multiple security measures like data execution protection (DEP), address space layout randomization (ASLR), structured exception handler overwrite protection (SEHOP), export address table filtering (EAF), heap spray allocation (HAS), null page allocation (NPA), bottom-up random memory allocation (BUR), with no need to recompile software.  Flexibility in configuring: the mitigation actions are very flexible, allowing their application to all the processes chosen. This implies that it is not necessary to implement certain security measures to a whole product or set of applications (which might give rise to problems if a particular process does not support certain mitigation measures, such as those which do not support DEP).  Ease of deployment and use: EMET has a graphic interface from which it is possible to configure all the desired parameters, eliminating the need to modify register keys by hand or any other type of tricky configuration. Furthermore, it is easily deployable though group policies and the System Center Configuration Manager. Recently, EMET has published version 4 19, in which, apart from the functionality commented upon above, the following security characteristics are incorporated:  Certificate Pinning: perhaps one of the most significant of the functionalities of this new version of EMET is “Certificate Trust”. With this characteristic EMET permits the specification of rules through which it is possible to indicate the CAs (Certification Authorities) associated with an SSL 16 17 18 19 http://scap.nist.gov/events/2011/itsac/presentations/day2/Wilson%20-%20OpenIOC.pdf http://www.sans.org/reading-room/whitepapers/incident/ioc-indicators-compromise-malware-forensics-34200 http://support.microsoft.com/kb/2458544 http://blogs.technet.com/b/srd/archive/2013/06/17/emet-4-0-now-available-for-download.aspx THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 13 or TLS site. Well known events such as those affecting Comodo or DigiNotar demonstrate that a public key infrastructure (PKI) does not represent a security architecture sufficiently reliable to permit putting trust in a large number of bodies whose security policies are not as robust as they should be. EMET tries to reduce the need for trust, allowing users to associate an X.509 certificate with the certifying authority they choose. Figure 5 shows a “pin rule” in which the domain login.live.com is associated with the VeriSign CA. Any certificate used by Internet Explorer for login.live.com that originates from a different root CA from that configured in the given rule will be detected by EMET and reported as suspicious. Figure 5. Pin Rules in EMET.  ROP Mitigations: one of the exploitation techniques most often used to avoid DEP and ASLR are return oriented programming (ROP) gadgets. The idea of this technique is to seek out given sets of instructions in memory (for instance, DLLs) that can be used to call certain APIs in Windows so as to dodge DEP. This set of instructions must end in an instruction of the type RETN to be able to link to each of the gadgets that are constructed. As DEP prevents the execution of code from the call stack, all that will be stored in it will be the addresses for each of these gadgets. In this way, making use of the RETN instructions and the addresses stored in the call stack, it would be possible to execute code outside it. For example, if it were possible to find certain gadgets to call the function VirtualProtect(), perhaps the type of access to a given page in memory could be changed, marking it as executable, and thereafter particular shell-code could be lodged on that page. If, instead of VirtualProtect(), gadgets could be constructed to call the function SetProcessDEPPolicy(), it would be possible to deactivate DEP for the current process and execute code from the stack. Figure 6 shows an example of the ROP-chain generated by the script Mona.py from MSVCR71.dll to call VirtualAlloc().  Audit mode: if a vulnerability is detected, EMET does not kill the affected process, but rather reports the attack, letting the process continue. This mode is applicable only to certain mitigation measures, for instance those related to attacks that use ROP gadgets like those discussed above. This function avoids false positives that trigger unexpected shut-downs of applications, interfering with user activity. THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 14 Figure 6. Example of a ROP-chain Generated by the Script Mona.py.  To use EMET it is only necessary to launch its graphic interface and select processes and the mitigation measures it is desired to implement. As may be observed in Figure 7, EMET has two groups of configurations. On the one hand, there are those parameters that affect the system itself. On the other hand, there are those that are desired to apply to the chosen software. It is important to point out that EMET is totally dependent upon the operating system where it is installed, which implies that on a machine running Windows XP some security measures like SEHOP or ASLR (those shown in System Status) will not be available. THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 15 Figure 7. Configuration Groups in EMET. From Version 3 of EMET onwards, the configuration can be applied by importing protection profiles. These are just XML files defining the route for the executables it is desired to protect, which is an option of considerable use in transporting configurations from one piece of equipment to another. Figure 8 shows how to protect the Microsoft Office suite by using the Office configuration file Software.xml. Figure 8. Office Configuration File Software.xml. CRYSTALAEP 20 This is another tool employed in Windows equipment to prevent the execution of exploits in browsers and certain commonly used applications, cases in which antivirus software can do little. 20 Source: http://www.shelliscoming.com/2013/06/crystalaep-una-alternativa-emet.html THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 16 Similarly to EMET, CrystalAEP presents a multitude of protection options that can be selectively utilized with whichever applications are desired, to avoid attempts at exploitation. The application’s interface presents two configuration panels: Basic Options, from which it is possible to choose the applications that it is desired to add to the protection list; and Expert Options, from which it is possible to define in detail what security features to apply, generically or for each process. It is these last characteristics that make the application really attractive, thanks to the wide range of countermeasures available to avoid attacks corrupting memory. In view of the nature of many exploits, this type of measure should protect even against certain kinds of zero-day. As may be observed from Figure 9, from the Memory Monitor tab several of these options can be seen: • • • Enable Process DEP. Use-After-Free Protection. Disable RWX Heap. • • Vary Allocation Sizes. Windows Validate Allocations. Figure 9. One of the Configuration Menus of CrystalAEP. Likewise, in the API Monitor tab further protection mechanisms can be found, related to the API for Windows, such as Anti-ROP Stack and Additional Anti-ROP Methods, to prevent attempts at exploitation that try to make use of ROP gadgets in order to dodge DEP and ASLR. CrystalAEP also provides content filtering functionalities for IExplorer (Anti-Cross-Site Scripting, validation of PNG, JPEG and GIF files, and so forth). To see all these characteristics in detail, the user guide 21 for the tool may be consulted. CrystalAEP is free and is available 22 for Windows XP, Vista and 7 (32- and 64-bit architectures). SECURITY REPUTATION OF THE SOFTWARE AND/OR HARDWARE SUPPLIER One aspect that until not long ago had no special importance is the carrying out of checks on the reputation of software or hardware suppliers, in terms of the security of what they produce. Fortunately, recent news relating to the appearance of back doors or default administration accounts, the impossibility of updating firmware, and similar problems with devices utilized in SCADA architectures, has lead this aspect to be considered thoroughly when either applications or 21 22 http://www.crystalaep.com/CrystalUsersGuide.pdf http://www.crystalaep.com/download.html THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 17 physical devices are being acquired. For this reason, before making any purchase an assessment should be made of questions such as: • Do the devices or applications possess the appropriate capacities to allow management of their security? • Does the manufacturer offer security updates? LEGACY ENVIRONMENTS Built-in obsolescence may be defined as the fixing, planning or programming of the end of the useful life of a product or service such that after a period of time, calculated in advance by the manufacturer or the service provider during the design phase of the product or service, it will become obsolete, useless or unserviceable, or cease functioning. In contrast, authorized obsolescence corresponds to a decision to make permanent a system that, due to its structure or long life, has proved vulnerable or dangerous in controlling critical services when confronted with evolving techniques of attacking applications and infrastructures, but that, as consequence of an obligation to operate it permanently and without interruptions, cannot be replaced with up-to-date, more robust platforms. It is into this category that fall inherited or legacy systems, which despite being considered outdated cannot be replaced or updated in any simple way, because the impact on production or industrial processes is greater than the benefits of renewal. However, on many occasions there are other excuses for not replacing outdated systems. Nevertheless, a system considered as inherited must still comply equally with a series of conditions, which will oblige the operator to implement additional security mechanisms to protect it from threats. Some of the reasons that have been put forward to justify a refusal to update equipment and platforms are the following:  The sector is very conservative and not much given to changing things that in principle work well.  There are worries that software will cease to function after the application of updates.  Those responsible for the equipment are production staff and lack the means and the knowledge to take responsibility for keeping systems up to date. To make changes or modifications, they would need assistance, generally requiring contracts with third parties.  Very often developments are “made on demand” and after some years it is no longer possible to call on the developer or integrator who implemented the project so as to order solutions derived from the initial set-up.  Updating the operating system may require an update for the supervision software, necessitating work by external specialists, which once again implies a cost. However, as everything is working, no need is perceived to do so. The common denominator might be summed up in the sentence “If it works, don’t mend it”. The drawback is the definition of working that these systems have had since their distant beginnings, as it relates only to control and management, in total separation from security and auditing. Although some of these reasons might seem quite enough to justify the prevalence of retained software or devices, there should always be an in-depth analysis to allow more secure alternatives to what is in place to be sought. In any case, special attention must always be paid to the recommendations of the manufacturer of the system or the supplier of the product in question. THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 18 MOBILE EQUIPMENT Although remote access to critical systems is not a very advisable functionality, because of the nature of these systems, on occasion it is necessary to make available the information that is being generated by a given device, or simply to carry out monitoring tasks to check that everything is working properly. To undertake this type of action laptop computers, tablets, or similar devices are generally used. Hence, these devices, besides any security characteristics carried over from the main architecture (policies, security applications, and the like), must also have added to them security functions adapted to their physical nature, which makes them likely to be stolen or lost, for instance. Some of the characteristics that mobile devices should have include:  The device should be protected with a password and the data it contains should be encrypted.  The connections established between mobile devices and equipment in the installations should be encrypted to ensure the greatest confidentiality in communication. In many systems, to avoid access to data in the case of loss or theft, devices have applications that allow remote elimination of information, or even the complete wiping of everything contained. THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 19 4 CONCLUSIONS As in all Information Technology systems, in SCADA or industrial environments users are normally the “weakest link” from the point of view of security, and are especially vulnerable to what are called attacks based on social engineering. This is worse in the case of APTs (Advanced Persistent Threats), since besides being highly complex technically, these are attacks which are intentionally stealthy, with the aim of prolonging their useful life as much as possible. This guide brings together the measures that can be taken from the Operator’s Console to protect against these threats. Some of the most effective mechanisms studied are:  Restricting access and the services provided to what is strictly necessary. communications should be through secure channels. Furthermore, all  Implementing software updating policies.  Keeping security copies of everything important, even carrying out drills to check that the copies are correct and complete.  Deploying anti-malware measures on all devices permitting them. It is also essential to keep watch so that important information is not illicitly altered. Specifically, among the most effective measures are Host-based IDS: agents monitoring each piece of equipment individually; and Honey Tokens, which work as a trap to detect attackers and raise the alarm if there is an intrusion. For detection, IOC indicators are also useful, as by describing the technical characteristics of a threat they permit it to be identified unambiguously. Special mention should be made of mechanisms for protection against exploits (software components utilized to take advantage of security failures), since these are difficult to detect with typical tools, like antivirus software. For this aspect, the main components of the tools EMET and CrystalAEP can be used, for instance, to protect against unauthorized execution of code or to associate digital certification authorities with specific sites. It is also noteworthy that in the industrial sector it is relatively frequent to find outdated systems, known as "legacy systems", owing to the impact that replacing them would have. Nonetheless, these systems continue to be a part of the whole, and hence it is important to safeguard their security, despite their being "outdated systems". In any case, as a general rule, applicable to everything noted in the guide, it must be kept in mind that the recommendations of the manufacturer of the systems or products involved must always be respected. Finally, it should be recalled that there may be specific sector characteristics, needs and technologies affecting certain operator consoles that limit direct application on some of the measures envisaged in this guide. Applicability to individual environments has to be assessed proportionately to the technological factors, technical properties of the systems to be protected or the business model of the company concerned. On this point, the guide must hence be seen as a series of measures that are desirable, but not always strictly necessary, for improving the security of the operator’s consoles of critical infrastructures. In addition, as the guide is intended to cover protection of the operator’s console of critical infrastructures, which inherently needs enhanced security requirements, it is assumed that this equipment strictly adheres to corporate security policies, so that basic security measures, like the use of robust passwords, can be taken for granted. THE OPERATOR CONSOLE– A Basic Guide to Critical Infrastructure Protection 20