SEE project gets flak from RFP respondents

The request for proposal for the first phase of the government's SEE project for interdepartmental communications security has provoked grumbles among some potential bidders.

The request for proposal for the first phase of the government's SEE project for interdepartmental communications security has provoked grumbles among some potential bidders.

The bidders, who were not willing to be named, suggest the RFP was too vague in that it spoke from a business point of view and made insufficient stipulations on the desired technical architecture.

A related source of complaint stems from the project team's intention to provide a choice of three or four solutions, from which departments can select. All those solutions must, of course, be compatible. This means, says one bidder source, that "we are being asked to guarantee compatibility with other products, when we don't even know what those will be".

The first phase of the project covers secure email among government departments, and the RFP is for a pilot implementation covering the State Services Commission, the department of Prime Minister and Cabinet and Treasury.

It would have proved impossible to

impose a single security product on all government agencies, says Brendan Kelly, senior advisor in the e-government unit, because of government policy that a department's chief executive is solely responsible for the choice of IT systems and other products and services for his or her department. The multi-product approach will provide each chief executive with choice.

There should be no problem about compatibility, Kelly suggests, because the RFP specified that solutions be compatible with the S-Mime version 3 email protocol. If compatibility with this is preserved, all the email security products should be compatible among themselves, "apart, perhaps from the odd wrinkle", he says.

"One or two people may have been surprised" to see a business specification, Kelly says. "But we didn't want to put out an architecture specification because we didn't want to knock out solutions that might be quite viable and appropriate to our needs."

Initially, secure email was envisaged as running from client-to-client, with everyone in each department having their own digital certificate.

But prototyping established that there were some "usability problems" with that approach. So the direction now is to establish secure connections only between departmental gateways.

This means mail will be in unencrypted text over the LAN within each department, says Kelly. "So we lose some security."

Another problem militating against the client-to-client approach is the archiving of emails that only exist in encrypted form. There is no guarantee they will be readable in several years' time when an Official Information Act request might be logged for that information.

The change of direction meant the RFP was delayed. The project team is now evaluating the responses and expects to reach a conclusion in about two weeks.

The second part of the SEE project covers secure remote use by one department of another department's applications. The scope of this has been reduced to browser-enabled applications for simplicity. Two government agencies are prototyping this at present, and the issue of an RFP for this phase is dependent on the timescale of that exercise, and on development of business applications to support it.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments