Commentary

George Hulme
 

Citect Doesn't Get 'IT' When It Comes To Application Security

Citect, the Sydney, Australia-based maker of Supervisory Control And Data Acquisition (SCADA) software, CitectSCADA, doesn't seem to understand IT security, or why applications that run things like pharmaceutical plants, water treatment facilities, and natural gas pipelines should be inherently secure.

Citect, the Sydney, Australia-based maker of Supervisory Control And Data Acquisition (SCADA) software, CitectSCADA, doesn't seem to understand IT security, or why applications that run things like pharmaceutical plants, water treatment facilities, and natural gas pipelines should be inherently secure.As I'm researching SCADA system security today, I stumbled across this story, Citect SCADA Vulnerability Unlikely, in IndustrialIT. I'm not exactly sure why the story ran Friday, as I couldn't find anything new from the news reports that covered this SCADA vulnerability that ran a couple weeks ago. Essentially, Core Security Technologies found a remotely exploitable buffer overflow, and announced its find after Citect released the patch. Which, by the way, took five months to develop.

However, a line or two from the story leaped out, and punched me in the nose:


More Security Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

CITECT has responded to allegations of security problems in its SCADA solution by telling customers they are unlikely to be at risk if their systems are protected by industry-standard security guidelines.

This is almost a "throw-away" statement. They're saying that if the users of their software have all of the proper mitigating controls in place on their network, they have nothing to worry about. This is true of many application vulnerabilities.

It gets better:

The potential security breaches found by Core Security Technologies were limited to Windows-based control systems utilizing ODBC technology. However, they were only exploitable if the control systems were connected to the Internet without any security in place.

Did you catch that? Citect is saying that customers only have to worry about this vulnerability if they're connected to the Internet, and without any security in place. Now, most every application security vulnerability we get concerned about (browsers, e-mail, client applications) are "only exploitable if the system is connected to the Internet." And, if an adversary grabs physical control of your system, they won't be needing to run buffer overflow attacks.

What Citect doesn't seem to get is that applications should be built as inherently secure as possible -- from the jump. That means vetting applications for proper input validation, authentication, and other common programming gaffes that could lead to the compromise of an application. That way, should network security break down for some reason, even temporarily, customers wouldn't have to worry about a "remote, unauthenticated attacker" who "may be able to execute arbitrary code or cause a denial-of-service" as described in this US-CERT Vulnerability Note.

On its About Us page, Citect describes itself as having "The ability to develop powerful and reliable 'industrial strength' software, capable of withstanding the rigors of large-scale operations, has been one of our strengths."

Industrial strength software is great, it'd be even better if it could withstand buffer-overflows out of the box.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links