Tip of the Day: Standards

Published: 2006-08-27
Last Updated: 2006-08-28 16:48:35 UTC
by Swa Frantzen (Version: 3)
0 comment(s)
When I got interested in security in a more formal way than securing my unix boxes I administered in the early 90s, the first standard I found was RFC1244 (now obsoleted by RFC2196). Being technical staff in a university environment I found it overly complex at the time.

And since I'm still convinced many of us even today still think of security as a technical problem and not as the management problem it is, I'll try to promote thinking of security as a management problem:

Security in essence is managing risk.

In the late 90s I rediscovered some information security standards:
  • BS 7799 part 1
  • and a bit later BS 7799 part 2.
I learned to appreciate this as they do have interesting content to bridge the gap between the technical level that wants to fix things but often fails to see the management part and the management level that fails to understand the mechanisms and just wants it to support the business and cost as little as possible.

So what's out there from a standard point of view? And what do they address?

'7799 family


"Code of practice for information security management"

ISO17799 was formerly known as BS7799 part 1. "BS" Stands for British Standard. It is a standard that suggests a best practice and I find it often useful to grab my copy when e.g. writing requirements for a backup system as it makes me think about a dozen things backup needs to cover and makes sure that if I leave one of them out that I did it intentionally.

I also use it when writing policies as it tells me what I should cover in the policy in addition to what I come up myself.

It exists since 1994 and has been reviewed a few times. The pitfalls I knew in the pre 2005 version are mostly out of it. It addresses a wide range of items you want to control in a corporate viewpoint. It does go into detail on how you could gain that control. But it stays away from technical details.

This standard will be renamed to ISO27002 in the future.


"Information Security Management System Requirements" (ISMS)

ISO27001 was formerly known as BS7799 part 2. It exists since 1999. It tells you how to build a management system that manages your information security. It might seem even less technical and the size might be deceiving as it tells you to do a risk assessment for all your assets as one of the things it tells you to do. Now the implications of that are huge.

ISO27001 can be certified. A third party auditor can certify that you implemented it and it is seen as a quality label of your information security. I've seen a few RFPs that required a certificate to be able to content for the contract in the past.

The link to ISO17799 comes from the last thing to complete when doing it all and the first thing the auditor wants to see: The Statement of Applicability. It is a list of control suggested in ISO17799 that you decided you did not need with a justification for it. This does make the 100+ controls in ISO17799 somewhat mandatory, but then again they are best practices.


"Guideline for information security risk management"

This latest sibling if the '7799 family is "only" a British Standard at this point. BS7799-3:2006 is a set of guidelines on how to get one of the hardest parts of ISO27001 done: risk management.

It's IMHO rather thin at the moment, so unless you intend to certify ISO27001 I'd skip on it. Get another source for how to do risk management the easy way: do not go to far in the math part of it, just low/medium/high is hard enough to deal with.

Do not fear!

Get it! Read it!

While the above standards are not available for free download, do get a copy of them (legally of course). Especially the ISO17799 is a standard that is mature and can help you greatly when building an environment and when trying to expand or improve something in the existing environment.

Don't be silly!

ISO17799 is not a policy, do not copy it and say "our policy is to do this". You cannot do that as e.g. the very first control in there addresses itself to management and tells them:

"Management should set a clear policy direction in line with business objectives and demonstrate support for, and commitment to, information security through the issue and maintenance of an information security policy across the organization. "

So ... read the document, read the details, e.g. that goal above has a page of explanation on how to achieve it. and then act on the steps.

Don't try it all in one step. You'll fail. Try it one step at a time, prepare for each possible step and every time try to get more in it and make sure you try to continuously improve the situation. That continued improvement is also what ISO27001 will demand of you, especially if you try to certify it.

Other standards

Security standards

There are loads of other IT security related standards, I've by far never read all of them. And it seems that every time I look there are more of them.
  • ISO13335 is about IT security management. There are 5 parts in this.

  • ISO18044 is about incident management.

  • ISO18043, ISO18028, ISO15408, ISO18045, ISO15442, ISO15446

  • ...
There are also interesting IT related things to look into such as Cobit and ITIL (ISO 20000)

Risk management

A reader suggested the AS/NZS4360:2004 standard for risk managent. I did know about the '7799 family down under, but I'm happy to see there is a standard on risk management that's been aroung since 1994. This is especially important in the light of managing security essentially being managing risk.

Non security

I promise to be brief but I just must point out that other things such as environment, quality, etc. do have their own ISO standards and that those standard also build management systems and that they are compatible and even reference each other. So you might and up looking at ISO14001 (envirnoment), ISO9001 (quality) etc as well.


Go out and buy the ISO17799:2005, you'll love it if you take the time to get to know it. And it's a good ally if you need to write policies or RFPs.
Do watch out for certification as a driver to get this in motion. It can easily lead to a monster on paper that has no impact on the real world. And therefore is a waste of time and effort. 

Swa Frantzen -- Section 66

Keywords: ToD
0 comment(s)

J2SE Runtime Environment (JRE) & Java SE Developer Kit (JDK) Update 8

Published: 2006-08-28
Last Updated: 2006-08-28 23:06:15 UTC
by Tony Carothers (Version: 3)
0 comment(s)
Sun has released Update 8 to for JRE 5.0 for download.  As an earlier diary discussed, versions prior to 5.0, Release 6, allowed applets and/or applications to call earlier unpatched versions.  What is the risk to me?  Having the ability to call earlier, unpatched versions could potentially allow an attacker to run her/his code of choice along with it.  The Java Runtime Environment and Java Developer Kit both have release 8.0 available for download here.

Update: Here is a submission from one of our readers (who wishes to remain nameless). I am pasting it here verbatim. Just shows the quality of our readers that makes the ISC what it is. Thanks.

* If the previous versions of SunJRE aren't installed, and the user doesn't have local admin, it's pretty hard for an applet to successfully request a previous version!  When installing new versions of SunJRE, always uninstall the old one.

* That said, I have personally run into many situations where applets demand older versions of Java.  The main problem is internal corporate developers that want to ensure they get SunJRE even on machines where MSJVM is the default.  They generally tend to instantiate their Java applet using a CLSID, and they use the specific version CLSID (i.e. "{CAFEEFAC-0014-0002-0003-ABCDEFFEDCBA}"). 
Since I don't want to install old versions of Java, and I have absolutely no way of influencing the developers who maintain those websites, I have taken to subterfuge. 
What I do is add in CLSIDs for the earlier versions of SunJRE (the pattern is pretty obvious), but point them to the most recent patch level for SunJRE.  For instance, the following would point 1.4.2_06 to 1.4.2_12:

@="Java Plug-in 1.4.2_06"

@="C:\\Program Files\\Java\\j2re1.4.2_12\\bin\\npjpi142_12.dll" "ThreadingModel"="Apartment"

That seems to work as most of these applications don't really care about the differences between patch levels, and the applets don't test once Java loads, so as long as the CLSID is populated, Java starts right up.

I don't know if 1.4.2_12 and 1.5.0_06 populate these older CLSIDs automatically or if Java applets using old CLSIDs will simply fail to run.

0 comment(s)

Tip of the Day - Making the Switch

Published: 2006-08-27
Last Updated: 2006-08-27 16:02:23 UTC
by Tony Carothers (Version: 1)
0 comment(s)
Wi-Fi; most of us are using it, I am as I type this.  But how do I know my neighbor isn't watching what I do?  Because some time ago I dumped Wired Equivalent Protection (WEP) for the more robust, and unbroken as of yet, Wi-Fi Protected Access (WPA2).  WEP has been broken for several years, with a number of tools out there to exploit it.  WPA2, as of now, has yet to be broken.  Which are you using?  WPA2 Personal, a pre-share key type authentication implementation is very similar to WEP on the setup and administration side, but that is where it ends.  WPA2, or 802.11i, makes use of the AES Block Cipher, which as stated, has yet to be broken.

Now the Wi-Fi Alliance is set to launch WPS, or the Wi-Fi Protected Setup, which will make it extremely easy and versatile to deploy.  Instead of explaining it though I will let you read about it.....

Keywords: ToD
0 comment(s)


Diary Archives