Showing posts with label cybersecurity. Show all posts
Showing posts with label cybersecurity. Show all posts

Enhancing Cyber Security in Industrial Control Systems and Critical Infrastructure with Dynamic Endpoint Modeling

A white paper courtesy of Schneider Electric (Foxboro)

Cyber attacks against Industrial Control Systems (ICS) are on the rise, putting nations’ critical infrastructure at risk. In a paradigm shift from the traditional network security systems, a new approach — Dynamic Endpoint Modeling — learns and models the behavior of all devices on the network and triggers alerts when algorithms detect changes in learned behavior.

Read the entire white paper below.

Cybersecurity: Seven Steps to Effectively Defend Industrial Control Systems

Industrial Cybersecurity
Seven steps toward industrial cybersecurity.
Cyber intrusions into US Critical Infrastructure systems are happening with increased frequency. For many industrial control systems (ICSs), it’s not a matter of if an intrusion will take place, but when. In Fiscal Year (FY) 2015, 295 incidents were reported to ICS-CERT, and many more went unreported or undetected. The capabilities of our adversaries have been demonstrated and cyber incidents are increasing in frequency and complexity. Simply building a network with a hardened perimeter is no longer adequate. Securing ICSs against the modern threat requires well-planned and well-implemented strategies that will provide network defense teams a chance to quickly and effectively detect, counter, and expel an adversary. This paper presents seven strategies that can be implemented today to counter common exploitable weaknesses in “as-built” control systems.

If system owners had implemented the strategies outlined in this paper, 98 percent of incidents ICS-CERT responded to in FY 2014 and FY 2015 would have been prevented. The remaining 2 percent could have been identified with increased monitoring and a robust incident response.

1. IMPLEMENT APPLICATION WHITELISTING

Application Whitelisting (AWL) can detect and prevent attempted execution of malware uploaded by adversaries. The static nature of some systems, such as database servers and human-machine interface (HMI) computers, make these ideal candidates to run AWL. Operators are encouraged to work with their vendors to baseline and calibrate AWL deployments.

Example: ICS-CERT recently responded to an incident where the victim had to rebuild the network from scratch at great expense. A particular malware compromised over 80 percent of its assets. Antivirus software was ineffective; the malware had a 0 percent detection rate on VirusTotal. AWL would have provided notification and blocked the malware execution.

2. ENSURE PROPER CONFIGURATION/PATCH MANAGEMENT

Adversaries target unpatched systems. A configuration/patch management program centered on the safe importation and implementation of trusted patches will help keep control systems more secure.
Such a program will start with an accurate baseline and asset inventory to track what patches are needed. It will prioritize patching and configuration management of “PC-architecture” machines used in HMI, database server, and engineering workstation roles, as current adversaries have significant cyber capabilities against these. Infected laptops are a significant malware vector. Such a program will limit connection of external laptops to the control network and preferably supply vendors with known-good company laptops. The program will also encourage initial installation of any updates onto a test system that includes malware detection features before the updates are installed on operational systems.

Example: ICS-CERT responded to a Stuxnet infection at a power generation facility. The root cause of the infection was a vendor laptop.

Use best practices when downloading software and patches destined for your control network. Take measures to avoid “watering hole” attacks. Use a web Domain Name System (DNS) reputation system. Get updates from authenticated vendor sites. Validate the authenticity of downloads. Insist that vendors digitally sign updates, and/or publish hashes via an out-of-bound communications path, and use these to authenticate. Don’t load updates from unverified sources.

Example: HAVEX spread by infecting patches. With an out-of-band communication path for patch hashes, such as a blast email, users could have validated that the patches were not authentic.

3. REDUCE YOUR ATTACK SURFACE AREA

Isolate ICS networks from any untrusted networks, especially the Internet.b Lock down all unused ports. Turn off all unused services. Only allow real-time connectivity to external networks if there is a defined business requirement or control function. If one-way communication can accomplish a task, use optical separation (“data diode”). If bidirectional communication is necessary, then use a single open port over a restricted network path.

Example: As of 2014, ICS-CERT was aware of 82,000 cases of industrial control systems hardware or software directly accessible from the public Internet. ICS-CERT has encountered numerous cases where direct or nearly direct Internet access enabled a breach. Examples include a US Crime Lab, a Dam, The Sochi Olympic stadium, and numerous water utilities.

4. BUILD A DEFENDABLE ENVIRONMENT

Limit damage from network perimeter breaches. Segment networks into logical enclaves and restrict host-to-host communications paths. This can stop adversaries from expanding their access, while letting the normal system communications continue to operate. Enclaving limits possible damage, as compromised systems cannot be used to reach and contaminate systems in other enclaves. Containment provided by enclaving also makes incident cleanup significantly less costly.

Example: In one ICS-CERT case, a nuclear asset owner failed to scan media entering a Level 3 facility. On exit, the media was scanned, and a virus was detected. Because the asset owner had implemented logical enclaving, only six systems were put at risk and had to be remediated. Had enclaving not been implemented, hundreds of hosts would have needed to be remediated.

If one-way data transfer from a secure zone to a less secure zone is required, consider using approved removable media instead of a network connection. If real-time data transfer is required, consider using optical separation technologies. This allows replication of data without putting the control system at risk.

Example: In one ICS-CERT case, a pipeline operator had directly connected the corporate network to the control network, because the billing unit had asserted it needed metering data. After being informed of a breach by ICS-CERT, the asset owner removed the connection. It took the billing department 4 days to notice the connection had been lost, clearly demonstrating that real-time data were not needed.

5. MANAGE AUTHENTICATION

Adversaries are increasingly focusing on gaining control of legitimate credentials, especially those associated with highly privileged accounts. Compromising these credentials allows adversaries to masquerade as legitimate users, leaving less evidence than exploiting vulnerabilities or executing malware. Implement multi-factor authentication where possible. Reduce privileges to only those needed for a user’s duties. If passwords are necessary, implement secure password policies stressing length over complexity. For all accounts, including system and non-interactive accounts, ensure credentials are unique, and change all passwords at least every 90 days.

Require separate credentials for corporate and control network zones and store these in separate trust stores. Never share Active Directory, RSA ACE servers, or other trust stores between corporate and control networks.

Example: One US Government agency used the same password across the environment for local administrator accounts. This allowed an adversary to easily move laterally across all systems.

6. IMPLEMENT SECURE REMOTE ACCESS

Some adversaries are effective at gaining remote access into control systems, finding obscure access vectors, even “hidden back doors” intentionally created by system operators. Remove such accesses wherever possible, especially modems as these are fundamentally insecure.
Limit any accesses that remain. Where possible, implement “monitoring only” access enforced by data diodes, and do not rely on “read only” access enforced by software configurations or permissions. Do not allow remote persistent vendor connections into the control network. Require any remote access be operator controlled, time limited, and procedurally similar to “lock out, tag out.” Use the same remote access paths for vendor and employee connections; don’t allow double standards. Use two-factor authentication if possible, avoiding schemes where both tokens are similar types and can be easily stolen (e.g., password and soft certificate).

Example: Following these guidelines would have prevented the BlackEnergy intrusions. BlackEnergy required communications paths for initial compromise, installation and “plug in” installation.

7. MONITOR AND RESPOND

Defending a network against modern threats requires actively monitoring for adversarial penetration and quickly executing a prepared response.
Consider establishing monitoring programs in the following five key places:
  1. Watch IP traffic on ICS boundaries for abnormal or suspicious communications.
  2. Monitor IP traffic within the control network for malicious connections or content.
  3. Use host-based products to detect malicious software and attack attempts.
  4. Use login analysis (time and place for example) to detect stolen credential usage or improper access, verifying all anomalies with quick phone calls.
  5. Watch account/user administration actions to detect access control manipulation.
Have a response plan for when adversarial activity is detected. Such a plan may include disconnecting all Internet connections, running a properly scoped search for malware, disabling affected user accounts, isolating suspect systems, and an immediate 100 percent password reset. Such a plan may also define escalation triggers and actions, including incident response, investigation, and public affairs activities.
Have a restoration plan, including having “gold disks” ready to restore systems to known good states.

Example: Attackers render Windows®d based devices in a control network inoperative by wiping hard drive contents. Recent attacks against Saudi AramcoTMe and Sony Pictures demonstrate that quick restoration of such computers is key to restoring an attacked network to an operational state.

Defense against the modern threat requires applying measures to protect not only the perimeter but also the interior. While no system is 100 percent secure, implementing the seven key strategies discussed in this paper can greatly improve the security posture of ICSs.

DISCLAIMER

The information and opinions contained in this document are provided “as is” and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

ACKNOWLEDGMENT

This document “Seven Steps to Effectively Defend Industrial Control Systems” was written in collaboration, with contributions from subject matter experts working at the Department of Homeland Security (DHS), the Federal Bureau of Investigation (FBI), and the National Security Agency (NSA).

Cybersecurity, ISA, and Automation Federation and How We Got Here

Author, Stephen R. Huffman, Vice President, Marketing and Business Development, at Mead O’Brien, Inc.
Published: InTech Magazine, May-June 2015

Cybersecurity and
Automation
Technical leaders had the foresight to create the ISA99 standards committee back in 2002. They recognized the need for cybersecurity standards in areas outside of the traditional information technology (IT), national security, and critical infrastructure areas of concentration at the time. In the following years, a number of ISA99 committee members spent time and effort advocating and even testifying on Capitol Hill about our profession, which was not well defined, and our cybersecurity efforts therein, which were not well discerned from IT perceptions.

When Automation Federation (AF) refocused its efforts in 2007 with both automation profession advocacy and industrial automation and control system (IACS) cybersecurity as two of its strategic imperatives, we ventured forth to Capitol Hill with a message and a plan. We found that in general our lawmakers equated process and industrial automation as “IT” and thought that IT was already addressing cybersecurity in terms of identity theft and forensics, and that the Department of Defense was handling cyberprotection for national security. For the next several years, AF built its story around cyberthreats in the operational technology (OT) area and how ISA99 through its series of standards, technical reports, and work group output was providing guidance for asset owners, system integrators, and control system equipment manufacturers specifically for securing IACS.

The operating philosophy of IT cybersecurity versus OT cybersecurity is quite different. Although the approach of shutting down operations, isolating cybersecurity issues, and adding patches may work well to mitigate IT breaches, the same cannot be said for operating units in a real-time process. In short, it really is not feasible to “reboot the plant.” The message resonated enough for us to help create the Liebermann-Collins Cybersecurity Senate Bill introduced in 2012, but opposition (more political than reasonable) doomed this first effort.

In 2013, the President issued Executive Order 13636 for enhancing cybersecurity protection for critical infrastructure. It included directing the National Institute of Science and Technology (NIST) to establish a framework that organizations, regulators, and customers can use to create, guide, assess, or improve comprehensive cybersecurity programs. Of the more than 200 proposals submitted by organizations receiving a request for proposal, almost all were IT-based. The AF/ISA submittal took the perspective of operational technology backed by the strength of the existing ISA99 set of standards. After a set of five framework meetings of invited participants, including the AF “framework team,” over the course of 2013, the OT and IACS teams were much more successful in defining the needs, and the automation message was much better understood. NIST personnel with legislative experience with AF on the 2012 Senate bill understood that private industry is a key piece of the cybersecurity and physical security puzzle.

AF organized a series of NIST framework rollout meetings in 2014 around the country with attendees from the AF team, NIST, and the White House. The meetings were hosted by state manufacturing extension partnerships, which are state units of NIST. After these meetings and more work with Senate lawmakers, a bipartisan Senate bill, The Cybersecurity Enhancement Act, was signed by the President and put into law in December 2014 (www.congress.gov/bill/113th-congress/senate-bill/1353). In summary, the act authorizes the Secretary of Commerce through the director of NIST to facilitate and support the development of a voluntary, consensus-based, industry-led set of standards and procedures to cost effectively reduce cyberrisks to critical infrastructure. As you can imagine, ISA99, now IEC/ISA 62443, will play a more prominent role in securing the control systems of industry in the future through a public-private information-sharing partnership. Thanks for the foresight and fortitude of the ISA99 standards committee.