Monday, November 17, 2014

What do concussions and cybersecurity have in common?

Recently, I attend a presentation on concussion management in youth athletics. The session was offered by two prestigious doctors from the Philadelphia metropolitan area - a neurologist and a psychologist - and provided a thorough report on concussion symptoms, the effects after one takes place, and the approved processes and procedures for managing and treating these injuries. Along with the overview came a disclaimer: while science and medicine have advanced and there are now better ways to detect, manage and recover from concussions, doctors in some states are bound to certain outdated procedures that have been codified into law.

At first, I was aghast. Imagine a physician on the bench or sidelines of the local high school’s game of the week. The doctor is trained, ready, willing and able to provide the most effective treatment to an injured child. Unfortunately, because of the regulations, the doctor is not permitted to do so without jeopardizing his right to practice medicine in his state. 

Oddly enough, this scenario seems all too familiar to me. This is a story I’ve heard many times before in my discussions with industrial facilities around the world. Much like the doctor who wants to provide the best treatment, utilities and industrial plants generally want to deploy the most appropriate cybersecurity solutions available to protect their employees, assets, and customers. However, these organizations face the same challenge as the doctors – overly prescriptive and out-of-date regulations.

Many believe regulations to be an effective means to engage utilities and industry toward cybersecurity. When first introduced, regulations are highly successful in guiding the development of up-to-date cybersecurity programs. However, over time, regulations with the best of intentions quickly become checklists to establish compliance with the legislated standard. The explicit requirements can significantly hinder innovation, which is often an unintended result. Worse still, the nature of the bodies that author these regulations – in regards to both the medical profession and cybersecurity – tend to adapt to new technologies slowly. This hinders organizations from taking advantage of the latest research and development.

Regulations are necessary to provide guidance and to establish minimum requirements, but codifying procedures and technology sets organizations up to fail – literally. Outdated procedures and technology leads to compromised systems. To stay truly safe and secure, we must encourage regulators to become more adaptable. 

We do our part at Waterfall Security to impact regulation changes.  What can you do?

Friday, November 14, 2014

Patching critical infrastructure: What Bash means for ICS security

On September 25, a bug deemed “Shellshock” was discovered in Bash, a command shell on Unix, Linux and Mac OS X operating systems that is used heavily in scripting and for communication between one program and an operating system for certain kinds of services. Much of the media attention has centered on how Shellshock is a threat to cybersecurity in general, lumping all practice areas under one umbrella. Since critical infrastructure networks are much more difficult to patch and update than corporate networks, many control system security practitioners are wondering what, specifically, are the implications of Shellshock on control system networks, and what can we do to protect against these vulnerabilities. Surprisingly, a recent search of the Internet yielded no clear summary of the impacts of Shellshock on control networks specifically, hence this posting.

In order to be affected by Shellshock in the first place, a device must have Bash installed. Since Bash is not a standard Windows component, it’s unlikely that Windows systems will be vulnerable unless the program was installed for some reason. Mac OS X and Linux both use Bash heavily, and if any non-Linux Unix is running on a network, then Bash is also very likely deployed somewhere within that system, if not everywhere.

Here are some examples of how Bash might affect particular systems:
·         Web servers that use CGI scripts, like Apache, transfer information like the “user agent” string directly to Bash. That string can be set in some browsers, and is easily set in many popular command-line Internet tools. The exploitation of these vulnerable web servers is trivial. This compromise can be accomplished from any IP address that has access to send a web request into the vulnerable server.
·         Most Mac/Linux/Unix gear that uses DHCP on an industrial network is ripe for an attack from the local network. While most critical control systems have been drilled into using static IP addresses rather than DHCP for exactly this reason, some sites still have equipment using DHCP. If a hacker can get his hands on a laptop or other computer connected to a control network and can turn on a DHCP server on the machine, all bets are off.
·         Every device that runs Linux or some other Unix derivative with Bash installed, and has a Web user interface, is vulnerable. This includes a lot of networking gear, firewalls and even some RTUs, PLCs and other equipment. Figuring out which of these firmware-based systems have Bash installed is problematic in itself. Vulnerable equiment can generally be hacked by any machine, which can send a message to the Web server.

Software and firmware updates should of course only be applied to equipment on control system networks after thoroughly researching a patch’s reliability. In principle, while patches are being tested, or in some cases still being developed, all vulnerable DHCP, web and other functionalities should be disabled. This is easier said than done since it is not even clear which devices with embedded Unix-based operating systems have Bash installed at all, not to mention that some of the affected functions may be essential to the current design and operation of the control system.

This is just another example of why many control system vendors deploy Unidirectional Security Gateways. The gateways replicate servers to external networks to provide seamless, safe integration of control system networks with corporate and other networks. IT teams can then feel free to install the latest, up-to-the-second updates to all equipment on corporate networks, including the replica servers, without putting critical operations at risk.

The takeaway here is nothing new, and yet, is underlined with each new serious vulnerability. And all software has bugs, some of which are security vulnerabilities, meaning all software can be hacked. Industrial users should deploy hardware-enforced, stronger-than-firewalls perimeter protections to ensure that the next Shellshock, or dozen Shellshocks, do not expose critical infrastructures to attacks from corporate networks, and from the Internet beyond those networks.

To find out more about ICS security solutions, check out our products page here.

Monday, November 10, 2014

Waterfall/Area 81 Racing Team Podiums Twice at Goblins Go Double SARRC

Fall at VIRginia International Raceway has always been an enjoyable experience for the Area 81 Team. Cooler temps, beautiful scenery and a relaxed atmosphere makes the Goblins GO SARRC a staple on the Area 81 Racing Team calendar. Both drivers stepped up on podium for both races. Saturday's results were Richard second, Tim third. Sunday's results were swapped between the drivers with Tim taking second and Richard third. Overall a good weekend for the team.

“We made several improvements to the car since our last race here in the spring, so we were chasing setup all weekend. I qualified eighth overall and third in class for the first race, but quickly passed five cars and was third overall and second in class. The car developed under steer in Turn 6 soon after that. I hit the outside curbing and it sent the car spinning across the track. I didn't hit the tire wall but it was too close to get the car turned back on the track. We don't have reverse so it was left to the discretion of race control to get me pushed back. The car overheated during the long delay and I had to bring it in. The shunt must have affected my alignment and the car handled worse on Sunday. I spun again during the second race but was able to get back on before losing class position. I was disappointed to be several seconds slower than I was in the spring and couldn't compete for the win. I'll be ready to defend my championship in the spring. Special thanks to Matt Bell and Timmy Orr for filling in as crew in the absence of my crew chief. I couldn't have made the race without them!” -Tim Pierce, Car 18

“The newly re-paved VIR track has been a bit of challenge for me. All weekend, the car ran fine and it was certainly fast, but just lacked overall downforce for the turns. That being said, I had a decent race weekend with second place Saturday and third place on Sunday. Saturday's Race 1 was fairly uneventful after the first couple of laps I was by myself. I saw Tim go off in Turn 6 and hoped he and the car was okay. Qualifying for Sunday's race was going well and the tires had just warmed up, when I broke a throttle cable on my fourth lap. Sunday's Race 2 was full of consistent laps, however the car just lacked a bit of speed in the corners. With all the racing, I expected the new paving to get rubbered in and gain some grip, but that was not the case. Either way it was an enjoyable weekend at VIR with great weather and great social interaction within our team plus NC Region SCCA Members.” -Richard Franklin, Car 81

Next event for the Area 81 Racing Team will be the Last Chance SCCA Time Trials at Roebling Road Raceway, Savannah, GA on Nov 16-17th, 2014. Stay tuned to our website,, or Facebook for updates.

Wednesday, November 5, 2014

Waterfall/Area 81 Racing Takes SARRC F1000 Championship in Daytona

The 2014 points season concluded at the SARRC Invitational Challenge at the world-renowned Daytona International Speedway over the weekend. Area 81 Racing’s Tim Pierce was tied for first and Richard Franklin 11 points back in third place going into their first appearance at Daytona. Four F1000 competitors were in the running for the SARRC Championship.  After the dust settled, Tim earned his first SARRC Championship with a second-place finish and second overall. Richard would finish a respectable sixth place in class and seventh overall.

Both drivers took advantage of the Friday test day to become familiar with the track and determine car setup for the high banks of Daytona. The Saturday qualifying sessions gave the team confidence, as Richard placed second in Q1 and Tim placed second in Q2. The Sunday race ultimately featured Tim starting second and third overall, with Richard in striking distance in fifth position and seventh overall. A Formula Atlantic, who held pole position, pulled off the track with mechanical issues during the warmup lap and Tim quickly slid up into his position on the front row for the green flag. A careful start put Tim in third on the opening lap and briefly in fourth place at the halfway point, but he was able to find a rhythm with a spectacular display of determination in back and forth passes to regain second place. Richard found himself out of the draft of the front group, but kept them in sight while in a battle of his own. Unfortunately, the race was cut short a lap when a disabled car pulled off in the infield hairpin and a full course caution brought out the safety car for the checker flag.

"There is no feeling like going 154 mph on the banks of Daytona. I had no idea my car would go that fast. We had the rare opportunity to test various aerodynamic profiles on Friday. My Firman RFR-1000 has always had great mechanical grip so I thought I could remove the wing elements for minimum downforce and maximum top speed. The chain developed a tight spot on Saturday and we did not have a spare. My dad told me to just run it until it breaks. I was a little nervous between the chain and the fierce fight with two other drivers, but we ended up finishing well enough to win the championship. We have faced extreme adversity throughout the year and that makes it so much sweeter. I’d like to thank Waterfall Security Solutions, BriKy Coolers and Franklin Insurance Agency, as well as my family, my crew, and the team. This championship would not be possible without their support." -Tim Pierce, Car 18
"Congrats to Tim for a hard fought 2014 SARRC F1000 Championship. He is a talented driver and has had to overcome some unfair/unwarranted mechanical issues in the past. Consistent points scoring wins Championships, and this year it was Tim’s turn to shine. As for Daytona, I was pleasantly surprised to find myself at the top of the time sheets on Friday’s test day.  The car had plenty of speed, so we didn’t really make any changes. Unfortunately, that meant I stayed at the same relative pace, while my competitors got faster.  The race was cut short by a couple of laps right off the start by a FA stopping on course on the warm-up lap. I had a fierce battle for 5th until the yellow came out again.   As six F1000’s lined up nose-to-tail, I was looking forward to taking advantage of the big draft on the restart, but by then the 12 lap race was over.  Reflecting on the year, I’ve still had a good SARRC racing season, with plenty of wins and podiums. Many thanks to my family, crew and sponsors; Waterfall, BriKy Coolers and Franklin Insurance Agency for making it all possible." -Richard Franklin, Car 81    

Want to know where you can see the Area 81 Racing team? Stay tuned to and Facebook for updates.

Monday, November 3, 2014

October news roundup: Are we ready for cyberwarfare?

The rising likelihood of cyberwarfare has been a prominent topic over the last couple of weeks in industrial cybersecurity press. The reports that politically-motivated hackers have no reservations when it comes to launching large-scale cyberattacks against a nation’s critical infrastructure did not mesh well with the news that most industrial control systems are understaffed and underprepared for the possibility of cyberwarfare. Attacks have become increasingly sophisticated, and hackers are determined to get around common firewall defenses through whichever means possible. Overall, this makes the ensured protection of our critical infrastructure all the more important. Here are some recent reports on the topic:

The lack of cyberattacks that have been directed at industrial control systems (ICS) in the past has made them extremely susceptible to future attacks, according to SC Magazine’s correspondent at the Stockholm International Summit on Security in ICS. Because control systems aren’t under attack from advanced threats, such as malware, nearly as much as large enterprises are, the likelihood of a successful hacking attempt is troublingly high. According to the article, there’s little incentive among critical infrastructure security professionals to fix a crisis that hasn’t occurred yet.

The motives behind hacker groups Dragonfly and Energetic Bear may have been misinterpreted all along, according to a new report from Dark Reading. The article claims that compromised companies were not from the critical energy sector, but rather suppliers for OEMs that served pharma and biotech. Dragonfly’s malware concentrated on uploading malicious code into systems that would reflect real-world ICS configurations. The targeted companies’ “trojanized” computers were connected to industrial control system utilities and drivers.

Stewart Baker, a former general counsel for the NSA, warns the industry that organizations have no reservations toward using cyberweaponry as a means to gain power on the international stage. This suggests that the future of international disputes will be settled on a digital battlefield, with the primary target being critical infrastructure, an area where knowledgeable political hackers know they can do a lot of damage.

Security professionals have discovered that Sandworm, a hacking organization with links to Russian cyberespionage, are likely going after industrial SCADA systems that use products from GE Intelligent Platforms by way of malware. Researchers from Trend Micro claimed that the hackers used files that run through the application, CIMPLICITY, in order to gain closer access to the programs that run in conjunction with SCADA systems.

Peter Behr and Blake Sobczak look at how a large amount of basic vulnerabilities affecting power grids, factories and pipelines have gone largely unaddressed. This is as a result of the sensors and remote controllers that play a huge role in transferring vital data throughout ICS being built without cybersecurity in mind. Thus, critical infrastructure is left with a gaping flaw in security by the design of the systems themselves.

Want to read more? See what we had to say about cyberwarfare earlier this year.