I recently went on a bug-hunt in a huge system that I knew next to nothing about. The reason I went on this bug-hunt was because, although I didn’t know the system itself, I knew what the system was supposed to do, and I can read and write all the programming languages involved in developing the system (C++, C and VHDL). I’m also very familiar with the protocol of which the implementation was buggy, so not knowing the system was a minor inconvenience.
These are some notes I took during the bug-hunt, some of which intentionally kept vague so as to protect the guilty.
The Globe&Mail dedicated half a page of the Report on Business section to managing your inbox today. People who work with me know that
- if you want to get ahold of me quickly, E-mail is not the way to go
- if you want a thought-out, thorough response, E-mail is the way to go
The flurry of DNP3-related vulnerabilities reported to ICS-CERT as part of Automatak’s project Robus seems to have subsided a bit, so it may be time to take a look at where we are regarding ICS security, and where we might be going next.
Of course, I’ll only look at communications protocol security in this context: low-tech attacks on the grid is outside the scope of this article. In stead, I will take a look at two questions: why the focus on DNP3, and what else could they, and should they, be looking at.
There have been a number of well-publicized security flaws in open source software lately — the most well-publicized of course being the OpenSSL Heartbleed bug.
Then there’s the demise of Truecrypt, recent bugs in GnuTLS and recent bugs in the Linux kernel.
So, is there a systemic problem with Open Source software? Does proprietary software have the same problem?
I don’t usually use this blog to vent frustration, but I’ve been reading standards lately…
There are four versions of the horse:
- Pony. Horses as the Good Lord intended them. Strong and sturdy, yet soft and cuddly; obedient yet intelligent; and I’m told they’re rather tasty too!
- Horse. All the qualities of the pony, without the esthetics.
- Donkey. The beta version of the pony: strong and sturdy, but none of the frills and quite a few bugs in the programming. Also: they don’t taste nearly as good (or so I’m told).
- Ass. What the beta version became when the PMO took over.
- Cow. A forked-off project from the (then open-source) Horse project that went for taste, combined with a bigger ass for the workload (in the form of an ox — you didn’t think I misspelled ass, did you?)
- Dromedary. When some of the committee members got tired of trying to reach a consensus, they took what they had and ran with it — even if it’s running was more than a bit awkward.
- Camel. None of the looks. Some of the features. Some features you didn’t think a horse should have. Some you didn’t think a horse could have. More of the smell. Much, much more.
When you count, that doesn’t add up to four, does it?
That’s what design by committee is all about!
Vlinder Software is happy to announce the new website for the Arachnida HTTP(S) webserver/client framework is now live. You can find documentation and information for the webserver/client framework at arachnida.ca. Information will be added to the site on an ongoing … Continue reading
Automatak will be releasing the Aegis fuzzing tool publicly and for free for the first time in a few days. Like I said yesterday:
to which Adam replied:
I don’t think the industry is ready — and here’s why.
In this post, I will take a brief look at how using type lists can help optimize certain applications.
For one of the projects I’m working on, I needed a compile-time version of the KMP algorithm in C++. I started by making the algorithm functional.
In North America, ICS security, as regards the electricity grid, is regulated by NERC, which provides and enforces, among other things, the Critical Infrastructure Protection (CIP) standards.
In this post, I’ll provide a quick overview of those standards, provisions slightly more in-depth information than in my previous post.