Mitigating IC Vulnerabilities

Mitigating IC Vulnerabilities

Service vs. security.

The constructs of service before security led to the development of OPC-UA architecture. Business proficiency pushed improvement of the original design of Object Linking and Embedding (OLE). The development of OPC-UA came about for the provisional layer of common interoperability, information exchange, and process orchestration (Massaro, 2008). As a result, ICS’s acquired a service above security vantage deficiency. Industry requested developers to integrate diverse information trees and unify Data Access (DA) with Alarm & Event (A&E) for a singular methodology because of the difficulty attributed to dual data sets between A&E and DA servers and intent to ease data reconciliation (Luth, 2004). This has moved ICS’s to Internet accessibility, further complicating security and opening the door to event falsification and IC reprogramming techniques. Service Oriented Architecture (SOA) made remote software applications available for use in ICS’s (Paine, 2008). Remote capabilities allow external access to ICS’s via the Internet. Original ICS designers intended to deliver meaningful layouts though many systems suffer from the common problem of poor design and diminished reliability. Some flaws are inherent, while others include by poorly executed field modifications when onsite staff may be less knowledgeable of critical aspects within these systems (Zatarain, 2005). OPC-UA technology requested integrated ICS’s and delivered them to the Internet’s platform of insecurity. Because the design of the Internet is for research and packet transfer, cyberspace has several technical failings and vulnerabilities. Keeping systems subject to its design secure is improbable (McCusker, 2006).
Acquiring improved security for CIKR organizations through the government’s voluntary strategy has had little participation (Harwood, 2012). Since there is no mandate, these organizations choose to handle their own security. Without oversight, determining vulnerabilities for such sites is near impossible. Reasons related to non-participation are current government regulations and liability pertaining to associated risks (Harwood, 2012). The DHS has developed a CIKR requirement book to deliver comprehension about the requirements process for operational necessities (U.S. DHS, 2010). While the book may serve those who employ its resources, there is no guarantee of its use.

Corporate vs. industry.

Evaluating corporate perspectives against those of industry provides an understanding of the difficulties of mitigating risks within ICS’s. Relating corporate versus industrial decisions is possible through review of the Basic Control Loop. Shown in Figure 7, the Basic Control Loop presents the important aspect of control.

Maintaining control occurs through the decision and information process whereby the absence of either reduces efficacy (Carroll, 1966). The operational cycle handled by the control loop indicates that influences for a task come from the corporate and industrial levels. In order to allow business management software to forecast maintenance trends and monitor performance corporate leaders have placed these networks at risk (Lynch, 2012). Corporate decision-making has overlooked the vulnerability of these networks when mingled with enterprise data. While economics is a factor for consideration, failure to weigh continuance of the physical attributes of maintenance and development does not complete the loop. Consideration of the full system is precedent (Carroll, 1966). Ensuring networks are secure from the engineer’s perspective has surpassed the
simplicity of systems known three decades ago. Previously, an engineer had no need of IT concepts or knowledge of using human machine interfaces. Unrealistic expectations for prospect engineers of CI span multiple fields and concentrations. Figure 8 displays a job listing by the City of Tacoma.

Human Resource departments are developing job descriptions that touch several professional fields where a singular application is probably not suitable. Table 1 displays the separation of  requirements between ICS and IT technicians.

Today, an engineer is responsible for safe and dependable layouts inclusive of risk analysis as well as communication and control principles (Lusignea, 2013). In terms of the corporate vantage, complications causing service outages due to manual changes result in security being ignored (Lieberman, 2012). Declined invitations and involvement in security assessments provided by the DHS indicate cybersecurity ignorance within CIKR organizations (Harwood, 2012). Investments to protect ICS’s against vulnerabilities have been minimal (Moore, 2010). Profits drive corporate business views. Placement of profits above service continuity is a policy that generally alters only in the advent of adverse publicity (Alexander, 2011). Much of all code produced does not receive the reliability consideration that it should. Though the issue may be new to engineers working with ICS’s, the problem has been relevant since the writing of the first software code (Alexander, 2011). The issue is a known deficiency for corporate leaders as “Patch Tuesday” is now a common term. Engineers and operators depend on corporate executives to provide them with reliable tools. Those ICS executives that fail to demand better code from vendors, compound system vulnerability. The pace and complexity of threats require senior executives to confront these problems while retaining innovation and growth (Kaplan, Sharma, & Weinberg, 2011).

Typical security technology.

Unlike a typical IT network, an ICS network does not need exceptional throughput. However, an ICS is far more time-critical, with each specific installation
detailing tolerable levels of delay (Fergus, 2009). Their need to remain self-sustaining is significant. Unforeseen outages are unendurable and the systems’ continuous nature demands availability (Fergus, 2009). The ICS system platform is fragile in terms of standard IT Security. Integrating the ICS with defense capabilities such as antivirus or intrusion protection in real time
is not possible due to its vulnerability to network manipulation, disruption in timing, and specific need of expertise (Fergus, 2009). Table 2 indicates the differences between standard IT networks and the typical ICS network. The basis of security relies upon the premise of Transmission Control Protocol and Internet Protocol (TCP/IP). The growing reliance on IT technologies has made it easier to interface with ICS’s and reduced their previous isolation from network attacks (Byrnes, Franz, Carter, & Peterson, 2007). This improved technology attaches greater risk and the benefits require deeper concern. Highlighted below is the complexity of the problem It is our belief that the most serious issue for OPC is that configuring OPC applications securely have proven to be a major challenge for most engineers and technicians. Even though OPC is an open protocol with the specifications freely available, users must wade through a large amount of very detailed information to answer even basic security questions. There is little direct guidance on securing OPC, and our research indicates that much of what is available may actually be ineffective or misguided. Overall, there is little doubt that some clear advice would be very useful for the control engineer on how best to secure currently deployed, COM/DCOM-based OPC systems. (Byrnes et. al., 2007, p.6) Until recently, the standard IT enterprise security posture was the only application to devise defensive applications for an ICS. Use of firewalls, encryption, authentication measures, and other common metrics do not perform as efficiently for industrial platforms. Firewalls, the primary restrictive component for locking down networks, do not provide adequate utility to defend against industrial threats. Tofino Security has constructed a security appliance for IC’s which restricts all traffic except that specifically stated by the appliance (Tofino, 2013). With this device, the IC has its own firewall. Tofino’s design also allows engineers to devise and develop security zones within its flexible hardware/software product when deployed across an ICS. The application seems to afford promise, yet other opinions exist. There is no single solution to apply complete defense for ICS networks (Jacobs, 2013). Jacobs states that understanding the total scope is important. Product purchase will not solve cybersecurity issues; risk assessment is the starting point (Jacobs, 2013).

ICS configuration weaknesses

The presets for ICS’s are another distressing factor. A common weakness exists for many modules. Their Ethernet cards have hard-coded default passwords that are easily found in published support manuals (Paganini, 2012). Patches cannot fix these hard-coded faults; retirement of the hardware is required to mitigate the problem (Paganini, 2012). With the coming advances, vulnerabilities will expand. The electric grid configurations will require more communication control capabilities introducing added access points (Craig Jr. & McKenna Jr., 2012). The exposure of these networks will increase. Due to the deployment of smart meters, intelligent appliances, and other sensors the number of managed devices within residences will expand to between ten and a hundred (Craig Jr. & McKenna Jr., 2012). Adjacent to vulnerability caused by exposure is interconnectivity. Bridged heterogenous networks will create risks extending from the linking of those networks (Craig Jr. & McKenna Jr., 2012). Wireless integration continues to move forward with many circuit boards having the antenna printed on the board (Zwan, 2010). Complex systems will become more complicated. Increased complexity will further stress systems with the implementation of more points of failure (Craig Jr. & McKenna Jr., 2012). Standard IT risks will multiply. The added necessity of common computing technologies such as multipurpose operating systems and routable networking will increase problems prevalent in the office environment (Craig Jr. & McKenna Jr., 2012). Manual operations will decrease. Those decreases will lead to more automation which amounts to compounded risks (Craig Jr. & McKenna Jr., 2012). The North American Electric Reliability Council (NERC) has noted the top ten vulnerabilites for ICS’s. These weaknesses are scaled as foundational, intermediate, and advanced and range from policy and procedure issues, problems with wireless networking, insufficient detection and reporting metrics, and more (NERC, 2006). The vast amount of information available on the web provides access to complete libraries of vulnerabilities such as those at SCADAhacker.com (SCADAhacker, 2014).

ICS network weaknesses.

The introduction of ICS networks to the modern perspective of business operation has presented many of the aforementioned security concerns. Their environments have been modified to consider commerce and trade first and leaving likely security effects with little regard (U.S. DHS, 2011). The lack of attention dedicated to security leads to more problems. The lack of focus for defensive measures introduces gaps in a system that without remediation may become back door access points (U.S. DHS, 2011). Visits conducted to ICS facilities due to response and assessments have revealed these vulnerabilities. Noted among these architectures is missing defense-in-depth deployment, zoning, little if any port security, and weak access control. The architectures are in parallel connection with corporate networks absent firewalls or demarcation zones (DMZ) to assist in protection from the Internet (U.S. DHS, 2011). Networks that exhibit the most exceptional risk should have welldefine security perimeters. Segmentation of these networks would limit immediate access during attacks. Configuration for firewalls should restrict data to appropriate network locales. Application of DMZ’s to large architectures can help to isolate roles and privileges. Removal of Available bypass access points within the ICS that allow firewall avoidance must occur. To further compound the weaknesses with ICS networks, audit and accountability practices are frail. Related to this matter are incomprehensible network architectures, minimal enforcement of remote authentication, media egress control, and poor intrusion detection monitoring (U.S. DHS, 2011).