Unisys Investigated For Covering Up Cyber-Attacks

Stony Stevenson writes "Unisys, a major government IT contractor, is reportedly being investigated for failing to detect cyber-attacks, and then covering up its failings. Two US congressmen have called for an investigation into cyber-attacks aimed at the Department of Homeland Security, along with a contractor (that would be Unisys) charged with securing those networks. 'The House Committee on Homeland Security's investigations led them to believe the department is under attack by foreign powers, and could be at risk because of "incompetent and possibly illegal activity" by a US contractor. The congressmen didn't name the contractor in the letter. However, the Washington Post on Monday reported that the FBI is investigating Unisys, a major information technology firm with a $1.7 billion Department of Homeland Security contract, for allegedly failing to detect cyber break-ins traced to a Chinese-language Web site and then trying to cover up its deficiencies.'" Unisys denies it all.

Page 2?

[clarkkent09]

I guess if nobody reads the article, they figure it's not that important where they (don't) start reading from? Or else Stony Stevenson likes to read articles from back to front? I wonder how many /. readers will even notice.

Here is page 1 anyway: http://www.washingtonpost.com/wp-dyn/content/article/2007/09/23/AR2007092301471.html?nav=rss_business [washingtonpost.com]

Re:Incompetence on both ends

[rindeee]

Don't know about DHS, but DoD requires this annually. Don't finish it, bad things happen. It's not the greatest training, but it's 'okay' and repeating it annually drives it home. The problem is that many of the breaches are not in fact the fault of (or involving) end-users. Rather, they can be traced back to poor perimeter security, lack of patching, etc...all responsibility of admin types.

Re:Hmmm...

[Richard Steiner]

Uh... Unisys had a patent on LZW, which CompuServe subsequently used w/o permission in their GIF format specification.

Re:Typical unisys

[chuckymonkey]

Let's just say I have insight into the subject and it would be extremely difficult to do. Heavy auditing, random inspections, random pen testing, and many many myriad things would get in the way of that. Also most networks in govt. are totally segregated (reference air-gap) from the rest of the world, so with anything actually sensitive it would be completely impossible. I know that you're going to scoff at that statement, but trust me when I say that the cost of offshoring anything like that would be extremely expensive not to mention illegal and when dealing with govt. contracts you play by their rules. They are very lucrative contracts and one violation can lose the entire thing, so it really isn't in a company's best interest to even try it with govt. contracts the risk vs. reward is much to great.

Re:Typical govt C&A hokum

[Rich0]

I'd say the same thing applies in many regulated industries where it is required to document that a computer system meets various quality standards.

Far more money gets spent on documenting that the system works correctly than actually making the system work correctly. Often you end up with a system that looks great on paper that has lots of bugs in actual operation. Lots of tests get written that look like they test something but which rarely uncover bugs. The whole exercise costs a fortune, and largely exists to satisfy auditors (whether internal or external to the company performing the exercise).

Techniques like agile programming, automated testing, code reviews, etc are shunned because they're non-traditional and don't generate lots of paper. There is a fear that in an audit a government representative who hasn't signed on to the methodology might hammer you to death over not having a 2000 page design specification and a load of tests written and executed by everybody from the programmers, to IT QA, to end users (often the same exact test gets reformatted and run by all parties just so that it can be said that everybody had a hand in testing).

I once had to evaluate whether it was safe to directly modify a particular database field in an application, and was relieved to see that this application had one of those aforementioned thick design specifications. Then I was dismayed to find out that the only documentation there was on the field was the fact that it existed, what table it was in, what it was called, what kind of field it was, and what it contained (WidgetCorrectionFactor = Factor used to Correct the Widget value - really helpful as if I couldn't have guessed that much from the field name!). Absent was any kind of documentation as to what code might reference that field or what tables might join to it. I could search the source for the field name, but then there wasn't any kind of documentation or flow charts indicating the typical system workflow or in what order the various routines might get called. It was like documenting all the cell types in an animal without bothering to indicate what the actual animal looked like and how everything went together. But the auditors loved the document.

The issue is that most often QA and management and external auditors have no way of knowing whether a piece of code actually works or not. So, instead they look for stuff they can understand - paperwork. The paperwork does tend to lead to some basic form of quality, but rarely does it lead to code that doesn't break down on all the various one-off-cases that don't make their way into human-executed tests. I'll take a simple automated test that can be executed against a matrix of input values against a complex human-executed test that only ever gets run once (and is likely not repeated every time a piece of seemingly-unrelated code is touched) any day!

And in any case...

[BrokenHalo]

Unisys are just another tech dinosaur that never made it out of the seventies.

FWIW, Unisys didn't exist in the seventies. I was there. I worked on both types of kit (in those days you either went with the herd and learned to use IBM, or you learned to be versatile).

IIRC it came about via the merging of Burroughs and Sperry/UNIVAC in about 1986 (in fact, to be specific, I think Burroughs swallowed Sperry).

Re:Typical unisys

[eudaemon]

More to the point, when companies lose contracts they lose to them to a small
circle of competitors and those competitors rehire most of the people who were on the contract.
In fact that is so common you usually take your tenure / seniority with you to the
next company. When a contract changes hands, it really means the management layer
and the interface between management and the government is being changed. Workers
by and large keep their jobs.