Jericho Forum to provide customers with good security questions to ask

The Jericho Forum plans to publish a set of guidelines to help organisations ensure they ask the right questions and get the right information before purchasing security products.

Rigid network boundaries can no longer operate in a world where workers access corporate systems from anywhere in the world, where data can be copied on to an easily portable device, and where information is increasingly shared with customers, business partners and suppliers.

Organisations need to combine security with flexibility and openness, but few of them have the requisite skills or resources to judge which products will do the job.

Help may be on the way. The Jericho Forum, a pressure group of major users which has pioneered the concept of 'deperimeterisation' over the last five years, plans to publish a set of guidelines to help organisations ensure they ask the right security questions and get the right information before purchasing security products.

"There is a problem with a lot of security because fewer than half the FTSE 100 have real CISOs," said Paul Simmonds, one of the founders of the Jericho Forum and chief information security officer at a large pharmaceutical company. "For everyone else, it is just one of their functions. Very few have large security teams. Outside of the FTSE, companies rely on the recommendations of their systems integrator. ...If you don't understand the problem, you don't know the nasty questions to ask, and you don't get a secure solution."

The Jericho Commandments

1.  The scope and level of protection should be specific and appropriate to the asset at risk.

2.  Security mechanisms must be pervasive, simple, scalable and easy to manage.

3.  Assume context at your peril.

4.  Devices and applications must communicate using open, secure protocols.

5.  All devices must be capable of maintaining their security policy on an untrusted network.

6.  All people, processes and technology must have declared and transparent levels of trust for any transaction to take place.

7.  Mutual trust assurance levels must be determinable.

8.  Authentication, authorisation and accountability must interoperate / exchange outside of your locus / area of control.

9.  Access to data should be controlled by security attributes of the data itself.

10.  Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges.

11.  By default, data must be appropriately secured when stored, in transit and in use.   The

Learn more about the Jericho Commandments.

The guidelines have been created from the combined experience of leading organisations within the Jericho Forum, and are mapped against the 11 "Jericho Commandments," a set of design principles that Jericho produced years ago to define how a borderless organisation might operate securely.

As well as providing customers with a set of good security questions to ask, Jericho says the guidelines will enable vendors to carry out an assessment on their own products, and even market them as "Jericho compliant."

"This is a generic standalone document. It will allow the vendors to come up with their answers and assess how well their products match up to them," Simmonds said. "If the vendor thinks they are in a good position -- and some are -- they will publish their self-assessment."

Simmonds said that, since everything that Jericho does is open source, companies will be able to take what they want from the document and incorporate it in their requests for tender from suppliers.

The definition of secure protocols, for example, provides an opportunity for security professionals to draw upon the document. Jericho's "4th Commandment," in fact, says that only secure and open protocols should be used, but as Simmonds points out, customers may not know what to ask for.

In this case, one key question is to ask vendors if they actually document all of the protocols that their system uses. "That is really useful information, because you can't configure firewalls without it. But most vendors don't do it," Simmonds said.

Customers should also ask whether all the protocols are secure, and whether they are switched on by default. "If you are going to give me the option of secure and insecure protocols -- for instance, for reasons of backwards compatibility -- I want you to have, out of the box, the secure protocols enabled and not the insecure ones," Simmonds said. "And I want you to provide me with documentation which says, if you're going to downgrade the protocols, these are the risks and potential problems, and this is how you mitigate. For instance, if you are going to downgrade from the secure protocol to the insecure one, your firewall should have this particular rule-set in it to mitigate the threat."

He described most of the advice as "not particularly arduous, just motherhood and apple pie," but said that for busy professionals with a lot of functions to fulfil, many of these points can get overlooked.

The guidelines are currently undergoing final editing and will be tried out by "a few tame vendors" during January, Simmonds said. Any feedback will be incorporated during February, and the final guidelines will be published at the RSA Conference in San Francisco on 1 March.

Read more on IT risk management