19 Responses so far.

1. Reviewing the COE Policy – office productivity suite file format discussion | AGIMO Blog says:

   February 17, 2012 at 11:47 am

   [...] relating to other aspects of the COE Policy can be made on the main post: Reviewing the Common Operating Environment Policy. GD Star Ratingloading… Common Operating Environment, consultations 1 Comment Post a [...]
2. Stephen Norman says:

   February 17, 2012 at 12:24 pm

   While I think the changes in this new policy are good, there are a few things I’d like to see before it becomes mandatory for agency compliance, specifically:

   1. An appendix that has a minimum of 3 SOEs listed, 1 for Windows, 1 for Mac OS X and 1 for an enterprise edition of Linux (Red Hat for instance). The SOE should also list the required server-side software (along with estimated costs – this could be a separate document) in order to comply with controls related to servers.

   This appendix should list the software that an agency should purchase in order to create an SOE that is in full compliance with all the mandatory, and where applicable, all other components listed in this document. If this cannot be done for each platform then the policy needs to undergo serious review and must be considered a failure.

   2. Could you please expand on what ...

   ... is required by “configuration must be endorsed by DSD”?

   3. Could you specify what is meant by centralised operating system patching?

   4. Could an estimate of the costs required to implement all requirements be provided as these must to be taken into consideration when mandating components that agencies do not yet have?

   5. For sections where the specifications are platform-specific, could these be split into separate sections. For instance, “Unnecessary functionality in the user interface is removed for the purpose of improving system performance” applies to Windows machines with the default theme, and not to Mac OS X or enterprise Linux installations.

   6. In Multimedia Viewer, it states the viewer must support one of the endorsed codecs, but does not provide a reference to where these codecs are listed.

   GD Star Rating
   loading...
   • John Sheridan - AGIMO says:

     February 21, 2012 at 5:14 pm

     Hi Stephen

     Thanks for your comments. Here are my views about them in order:

     1 . We have not ruled out developing SOE build guidelines for Mac OS X and Linux. At this stage we are continuing to focus on Windows as a significant majority of the Government desktop fleet owners have signalled their intention to move to Microsoft Windows 7 as part of their next upgrade.

     2 . DSD are the authority on matters relating to Whole of Government ICT security. Any COE Policy configurations are approved and supported (endorsed) by DSD before being released.

     3. Centralised operating system patching means that the patching of desktop operating systems is managed at a server (central) level.

     4. The cost varies from agency to agency. It’s important to note that to continue to comply with the policy, agencies have to build their next SOE in accordance with it. In the extreme, if they never build another SOE, the cost of compliance would be zero. In reality, in constructing a new SOE, the COE policy guides the possible choices. I’ve yet to see an argument that the COE policy is driving cost up.

     5. Agencies can make this judgement. If agencies are using Linux or Mac OS X Operating System and there are no issues with system performance, then removing unnecessary functionality in the user interface would not be required.

     6. You will find the endorsed codec on page 13 of the COE Policy under “Codecs”:
     • Must support a codec capable of video playback as defined by the MPEG-4 part 2 standard,
     • Must support a codec capable of audio playback as defined by the MPEG-1 or MPEG-2 Audio Layer 3 standard, and
     • On systems with an optical drive, must support a codec capable of DVD playback.

     We have also provided agencies with a set of build guidelines for a Windows 7 SOE based on the COE policy and experiences agencies have had. Much of the detail to which you refer above can be found in these. Given their technical nature, I don’t intend to seek public comment on them.

     I’ll also be answering your other comment on the other post.

     Thanks again for engaging with us.

     Regards

     John

     GD Star Rating
     loading...
     • Stephen says:

       February 22, 2012 at 9:27 am

       Hi John,

       Thanks for your reply. There are a couple of items I would like query regarding your response.

       1. I certainty understand the need to focus on Windows, given the majority of departments using it so I will rephrase my original question.

       Will the COE policy be tested against non-Microsoft platforms before being made mandatory throughout government departments?

       I’m sure you would agree that it is important that such a policy be platform and vendor neutral. If the policy is not tested against other platforms, there would be a risk that in the future, departments could find that they cannot select an operating system other than Windows that would meet all of the mandatory requirements.

       For example under “Firewall”, I am unaware of any product for Mac or Linux that meets all these requirements.

       This is not to say that either of these platforms are less secure than Windows, it is just the demand from ...

       ... industry has not been there to justify security vendors spending the time and money on this technology. Mandating the requirements for software that simply doesn’t exist would exclude these platforms immediately from being able to be used since they don’t meet the COE requirements.

       2. Under “Security Configuration”, control C states that the “Configuration must be endorsed by DSD.” Can it be assumed then that before the policy is made a requirement, the various platforms will be tested and SOE guidance provided. If not, then how would an agency not using Windows build their next SOE, given that no configurations will be available that have been approved by DSD?

       3. Could you please provide more specific information regarding centralised operating system patching? Whilst you have stated that this needs to be managed server side, you have not indicated how this would be achieved. For example, would an agency using WSUS or a platform equivalent be enough to comply with “server managed” or would a more comprehensive solution such as SCCM or Altiris be required to meet this requirement?

       4. Could a clause by added in “User Configuration” section B that states the a best practice configuration does not take precedence over the controls stated in the document? This would alleviate problems that could occur where the best practice for a platform conflicts with what is stated in this document.

       5. If DSD are going to be approving all SOE configurations, how much additional time is that likely to take before agencies can begin testing their own software against it?

       Also, what would be the process if a critical update was released, that according to DSD needs to be deploying with 2 days, but that also altered the configuration? If an agency were to apply the patch their configuration would no longer be endorsed by DSD and therefore could not be deployed, but at the same time it needs to be deployed due to the ISM’s own requirements? Could a clause be added in the document that resolves this situation with the appropriate action agencies should take?

       Regards,

       Stephen

       GD Star Rating
       loading...
       • John Sheridan - AGIMO says:

         February 22, 2012 at 5:18 pm

         Hi Stephen

         Several points:

         A Windows SOE pilot study was conducted to validate whether the COE Policy was able to be implemented across government SOE’s before the COE policy was first finalised and released. At that time, no agencies were using either Linux or Mac OS and therefore the cost of conducting a pilot for those OSs was not justified. If the situation changes, then AGIMO will provide such testing.

         The COE policy is reviewed annually. It is designed to be platform and vendor neutral when defining standards. Should the standards prove to be limiting as far as choice of platform or vendor, there is scope for revision.

         Windows SOE build guidelines, which assist agencies with the practical implementation of the COE Policy, are also available. Agencies may build and configure their SOE to their own requirements, so long as they comply with the standards outlined in the COE Policy and the ISM. A Linux or Mac OSX version of the Build Guidelines will be developed if required.

         Regarding centralised patching: the intent of the standard is to help ensure patching consistency within each agency’s SOE. The standard does not specify the operating system platform, nor exactly how the patches will be managed nor which technology/product is to be used. It can be achieved by agencies through all of the technologies you mentioned.

         Regarding best practice configurations – good idea – we’ll be putting that in, thanks.

         On approvals by DSD: DSD endorse the COE Policy. It is up to agencies to deploy and test their SOEs in accordance with the COE Policy and the ISM. DSD do not approve individual agency SOEs. The COE Policy requires agencies to report non-compliance. If a critical update was released by DSD that conflicted with the COE Policy then the former would take precedence. Agencies are already aware of this.

         Thanks again for your participation.

         John

         GD Star Rating
         loading...
3. Australian Govt re-kindles office file format war | Delimiter says:

   February 21, 2012 at 4:41 pm

   [...] week, AGIMO first assistant secretary John Sheridan published a new draft of the COE policy. He noted the high degree of interest in the office document standard. Consequently, AGIMO last [...]
4. Stephen says:

   February 22, 2012 at 9:53 pm

   Hi John,

   Could you provide some details on the pilot study, such as how many agencies were involved and how long the pilot took? How different were their SOEs and would all of those SOEs meet the requirements of this policy?

   Could you also please explain how the ‘no use of Linux or Mac OS X’ was determined? Even if only a marginal number of agencies were using the software it would justify the development of the build guidelines?

   Having these documents would also help to show that AGIMO and the government are not pushing Microsoft onto the desktops of their employees which still seems to be the case in regards to this policy, something which AGIMO has been accused of in the past.

   Since you have stated that neither Linux nor Mac OS X has been considered or tested in this policy, how can you be sure that those operating systems would comply ...

   ... with it? It seems very anti-competitve and presumptuous to assume that just because Windows itself has a particular feature, that the same feature would be available on other platforms and then to write a policy based solely on looking at this single platform.

   Also, not having the guidelines for other platforms going forward is going to restrict agencies from selecting other desktop operating systems in the future. From the way the policy is worded, agencies would be required to choose a base configuration that has been approved by DSD, which from what you’ve said would only be Windows? How could this not be seen as pushing agencies away from other competing platforms and to staying with Windows?

   I will provide a list of areas of the policy where there are Microsoft-specific comments or remarks in a separate comment.

   Could you also please specify what effect this policy will have on agencies that don’t or can’t comply with this policy? Surely if it is mandated it will be enforced? What will be the result for agencies that don’t, can’t or choose not to comply?

   Stephen

   GD Star Rating
   loading...
   • John Sheridan - AGIMO says:

     February 22, 2012 at 10:32 pm

     Hi Stephen

     Details of the original survey work and the pilot were in our post 12 months ago.

     I’m a little disappointed to see the discussion turning to claims of forcing Microsoft on agencies. There is no substance to such claims. The fact is that agencies are not seeking to deploy non-Microsoft SOEs at the moment. If demand changes then we’ll support it. Until it does, there is no reason to do this work.

     Agencies are required to report on their compliance. But please note that we are working carefully and continuously to reach consensus on this work. As difficulties are identified, we work to address them – successfully so, to date. There is plenty of consultation, good engagement by agencies and widespread support. Indeed, yours is the only dissenting voice on this post, despite the attention it has received in other places.

     I’d welcome the details you mention regarding Microsoft-specific comments – mainly because I thought we’d successfully removed them all. If you want to email them instead of posting them, the address is on the post.

     Regards

     John

     GD Star Rating
     loading...
     • Stephen says:

       February 22, 2012 at 11:29 pm

       Hi John,

       Thanks for your reply. Just a couple of quick rebuttals though:

       1) As you can see from my other post, I was able to identify 16 different statements in the policy (excluding the general remarks there) where Windows specific features or products are used. Given this, I would say there is certainly substance to the claims I’m making, though I’ll gladly back down and apologise if it can be shown that other platforms do indeed support these features.

       2) Given that you and I are the only ones that have commented on this blog directly it’s a bit hard not to say I’m the only dissenting voice. I did happen to read the blog post over Delimiter and as I see you’ve responded, saying that I’m the only dissenting voice in relation to the coverage is absolutely false.

       3) I realise I’m being particularly negative against the policy, but I want to ...

       ... state that I fully support it’s principals and objectives – it’s just the details we are getting hung up on.

       4) I also wanted to say I appreciate the information that is posted on this blog and the attempts made to help the government become more open and transparent.

       Cheers,

       Stephen

       GD Star Rating
       loading...
5. Stephen says:

   February 22, 2012 at 11:01 pm

   Hi John,

   Some parts of the policy appear to be very Microsoft centric. Here are some examples:

   1. “Unnecessary functionality in the user interface is removed for the purpose of improving system performance.”

   As stated previously, this applies to the selection of Windows or Windows Basic themes and does not apply to other enterprise platforms.

   Suggestion: This should be moved across into Windows-specific documentation and removed from the core policy.

   2. “Internet Browser” – “Must be able to be centrally managed and configured”.

   This can only be done using Group Policy and Internet Explorer. No other browser on no other platform supports this due to the level of separation between the browser and the operating system.

   Suggestion: This should be moved to into Windows-specific (or rather IE-specific) documentation.

   3. “Internet Browser” – “Must not allow end user to install unauthorised add-ins”

   Add-Ins is the Microsoft term used for browser extensions or add-ons, which is what other browsers refer to ...

   ... it as. This also is only controllable via Group Policy on Windows.

   Suggestion: This should be moved to into Windows-specific (or rather IE-specific) documentation.

   4. “Email Client” – “Must support shared calendars and contacts”.

   Clients other than Microsoft Outlook often separate these components into two or three separate applications, such as Apple’s Mail, Address Book and iCal or Mozilla’s Thunderbird and Sunbird.

   Suggestion: Break this section up into 3 separate sections, 1 for each component. Each component should be able to work offline, store the offline data securely and must support the use secure communication for the protocols.

   5. “Antivirus” – “Must not rely only on pattern based detection methods”.

   Heuristic analysis is very new on platforms other than Windows and whilst this is a very good feature, it probably is a bit early for it to be a ‘must’.

   Suggestion: Change ‘must’ to ‘should’ or ‘where possible’.

   6. “Antivirus” – “Where the client is virtualised the Antivirus solution may be installed at the hypervisor level for ease of management”

   Placing an anti-virus solution in the hypervisor is useful, but will do nothing to protect the virtualised environment. If this is referring to VDI, then this is a Windows-only technology provided by Citrix and/or Microsoft.

   Suggestion: This should absolutely be removed. The best practice from all vendors of virtualisation solutions is to treat virtualised operating systems as if they were physical ones, including anti-virus, firewalls and backup.

   7. “Firewall” – “Must be supported by central management and configuration”

   This is something that can only be done, to the best of my knowledge on Windows and by only 1 vendor on Mac OS X. There are no firewall applications on Linux that support this.

   8. “Firewall” – “Firewall must be able to change its configuration automatically based on location.”

   Public, Private and Domain are useful, but only available on Windows. There are a couple of solutions for Mac OS X that provide this functionality, but they are consumer products not meant for the enterprise. Linux has no software that can do this to the best of my knowledge.

   9. “Firewall” – “If the firewall solution incorporated into the operating system meets the required standards it should be used.”

   Windows Firewall with Advanced Security is indeed a very nice feature and it’s the only built-in firewall that supports these features, but it’s still only on Windows.

   10. “Firewall” – “For example iexplore.exe should be allowed to communicate out to :80 rather than just allowing any application to communicate out to :80″

   A nice example, but probably not the best application to choose given what’s been previously discussed.

   11. “End Point Security” – “Must support the disabling of external ports such as USB, eSata or Firewire to selected user groups”

   This is only supported by vendors on Windows and requires Active Directory in order to implement for ‘selected groups’.

   12. “End Point Security” – “Must support the disabling of optical drives for both
   read and write”

   As above.

   13. “End Point Security” – “Must support the prevention of unauthorised installation of USB devices such as scanners and cameras”

   As above.

   14. “End Point Security” – “Must support the prevention (and reporting) of the installation of unauthorised USB mass storage devices such as USB thumb drives”

   As above.

   15. “Operating Systems” – “Must be capable of supporting the principles outlined in this policy”

   Given the above this means only Windows, and in particular Windows Vista and above only.

   16. “To facilitate application white listing where possible, applications must be installed in the locations as detailed in the specific system build documentation for each platform.”

   Given that the only system build documentation that is currently, and as John has previously stated will be, available for Windows, ‘each platform’ is a bit of a stretch. Given this statement it is implied that build documentation will be made available for all platforms, not just Windows.

   17. “To support the goal of agencies being able share services, the packaging of software should be standardised…should look to use application virtualisation to achieve this.”

   Putting aside the licensing restrictions that would prevent agencies sharing virtualised applications, application virtualisation is again only available on Windows.

   18. “All standard products will have defined security configurations based on DSD’s and the vendor’s recommendations.”

   Does this mean that we’ll see a security guide for Windows applications and not others? What if a ‘standard’ product that an agency might want to use hasn’t been given a security configuration by DSD?

   19. “The security and user configurations for each operating system platform will be detailed in the specific system build documentation for each platform.”

   Given this statement in order to comply with your own policy the build documentation for each platform must be produced or the statement changed.

   20. “Agencies must ensure their environment remains compliant with the policy as published at the time it was developed.”

   If there are any agencies not using Windows Vista or above, how can they be expected to comply with this policy?

   And just a couple of final points:

   I would also point you to a principle at the start of the document which states “The COE must be flexible enough to meet the requirements of all the agencies.” If any agencies that fall under the FMA are not using Windows Vista or above, then by this statement you must provide an SOE for the platform they are using.

   With this policy resulting from the “Desktop Scoping Study (Recommendation 2)”, could a link be provided to the study to allow the public to view what the actual recommendation was?

   Given all of this, and I ask this in all seriousness, was any research at all done on the capabilities of other platforms before the policy written?

   Stephen

   GD Star Rating
   loading...
   • John Sheridan - AGIMO says:

     February 22, 2012 at 11:26 pm

     Thanks again for your participation. We’ll consider the matters you raised. I’d point out that some of the distinctions you are making are very fine indeed. I’m quite confident that most of these matters sit quite comfortably under the COE Policy rather than in the SOE build guidelines. That was also the opinion of the more than 20 agencies represented on the working group.

     As to your final points, I’m quite happy that the policy is flexible enough for agencies – and so are those represented on the working group, in the CIO Forum and in the CIO Committee.

     The Desktop Scoping Study was conducted to support the desktop hardware coordinated procurement activity. It contains a large amount of detail that refers not to the COE but to the means by which the government could save money in hardware procurement – as we have, reducing the cost of standard desktops from 56% above the Australian average price to 55% below and saving more than $14m in less than 2 years. I doubt we will release the study itself, as to do so would compromise the government’s commercial advantage but I’ll see whether we can post the recommendation in question. There are no secrets there though. The core of the matter has been explained earlier in this category of the blog.

     And yes, we did look at other platforms. Some of us even use them, particularly at this time of the day.

     Regards

     John

     GD Star Rating
     loading...
     • oiaohm says:

       February 26, 2012 at 3:46 am

       “I doubt we will release the study itself, as to do so would compromise the government’s commercial advantage but I’ll see whether we can post the recommendation in question.”

       How should I read this. Does this mean you got special deals that none of the non for profits and other support groups working next to the government can get.

       “And yes, we did look at other platforms. Some of us even use them, particularly at this time of the day.”

       Yet a proper testing of Office Suites for Cross Platforms support failed to happen.

       Cost evaluation for organisations the government depend on to support the elderly and the like interfacing with the government has also not been considered.

       So yes MS and others might give you software cheap knowing that the result will be that other small less well funded groups will have to buy software from them to interface with goverment.

       So yes save ...

       ... government 14 million might end up costing services to the community more.

       I have seen this in the form of government software that only operated on Windows with MS Office installed. MS office really was not required to produce the reports.

       So have you made a saving really or have you cost the Australian people by stealth. Really it would be good to see the full report to work if you have or have not.

       GD Star Rating
       loading...
       • John Sheridan - AGIMO says:

         February 26, 2012 at 9:24 am

         You should read it like this: the study was about how to buy hardware in a better way and then manage it better. It wasn’t a discussion of operating system choice. Such studies regularly consider competing strategies and negotiating points. Releasing them can adversely affect the Government’s negotiating position. It’s not a conspiracy – it’s just good business. As a result of aggregating federal government demand, better prices are achieved.

         The COE policy is designed to be platform independent and, to the best of our ability, I think it generally is. We haven’t made any operating system mandatory. We conducted a pilot study for a SOE to support the operating system that is used over 95% of government PCs. That’s how one does pilots.

         The COE policy does not dictate the format of documents submitted to government nor how government publishes them. As has been explained previously, it is about reducing costs for government and simplifying administration and maintenance. The choice of file format is about internal government interoperability only.

         GD Star Rating
         loading...
6. Australian Govt re-kindles office file format war | My Blog says:

   February 24, 2012 at 1:36 am

   [...] week, AGIMO initial partner secretary John Sheridan published a new breeze of a COE policy. He remarkable a high grade of seductiveness in a bureau request standard. Consequently, AGIMO [...]
7. More Microsoft Lock-in Under the Guise of ‘Standards’ | Techrights says:

   February 26, 2012 at 2:57 am

   [...] Reviewing the Common Operating Environment Policy [...]
8. oiaohm says:

   February 26, 2012 at 12:45 pm

   John Sheridan
   “The choice of file format is about internal government interoperability only.”

   Problem is what ever format you choose internally will not stay so. All history it never has and never will. As so as you are thinking internal government interoperability only you have screwed up the policy so badly its not funny.

   Reason departments will want the public submitting in a format they don’t have to convert so will ask for the internal format to be provided. If a document does not read by the software you are using a person can miss out on a tender.

   The idea of internal government interoperability does not exist basically. There is either interoperability or there is not. So either interoperability with everyone or interoperability with no one need to be the policy. Anything else you are creating bias in the Australian Computer market.

   The reason why the ...

   ... COE is required to be released to the public is that its effects don’t stop at the government computers.

   So this means that whatever is in the COE about interoperability will apply either directly or indirectly to over 70% of the computers in Australia.

   So as you say its only for internal you are tell fibs.

   File-formats mandate operating systems. OOXML basically mandates windows with MS Office to read it dependably.

   ODF is readable on Mac OS X, Linux, Windows and also will be Android with the Same software Libreoffice. So with ODF you would be able to say if file opens with Libreoffice version X government can read it. Thing is person getting version X to check is not go out and buy software to check. So there will not be compatibility problems from people trying to use old versions of the software or different versions of the software. Apple iOS(ipads and the like) do support the means to read ODF fairly dependable.

   If you think file-formats are independent to software you have it badly wrong. All software has bugs those bugs effect how files read even if they are the same format.

   The buy hardware bit secret I can understand that. “manage it better” management methods don’t need to be secret. In fact they can be independently reviewed.

   I would class independent reviewed as critical when you wake up your polices and software selection is the main force of what software gets used in Australia on all computers. (government, commercial and non for profits)

   The thing is some management methods can exclude the use of particular operating systems well. Slightly different methods can at times allow broader OS usage.

   If you need to hide how you are managing your systems ok we are using cfengine/puppet/what ever. I have to wonder what you have wrong. Like from LCA2012 we find out there that puppet/cfengine or anything like it is not approved for use with government. So this means you are doing lots and lots of manual configuration. Results is lots and lots of human errors.

   So I can understand why you don’t want to release how you manage your systems. Because its going to come out that is poorly done effort is required into getting tools approved for government usage to make it well done. This is not a secret Linux World knows your systems are poorly managed by lot of commercial standards.

   Sweeping stuff under carpet you might as well forget it we will find out and it will leak into a public video at times. Yes the UNISYS talk at LCA2012 that is current on Youtube. Cats out bag basically stop trying to hide it.

   Either you want the Linux World to help you get well managed systems or you don’t. Keeping secrets about what you want in a system management solution Linux World cannot help you.

   So yes that study at least some of it should be released.

   “the study was about how to buy hardware in a better way and then manage it better.” The manage it better bit should be release for review.

   GD Star Rating
   loading...
9. oiaohm says:

   February 26, 2012 at 2:53 pm

   Anyone wanting to understand why this COE is so badly stuffed up.

   Watch http://www.youtube.com/watch?v=JIQa1Avn_bY from 27:04 on.

   Be aware is common best prac in everywhere bar government to run configuration management software.

   Basically breaking new ground is basically forbin. So people like John Sheridan will run systems that are design to appear to work. But all they systems are really designed todo is enforce the status quo. So proper interoperability testing is not done.

   Proper R&D processes don’t exist in Australian Goverment to bring new products into approved to usage list. Instead each commercial provider has to take the risk of getting a new product approved and risk the fall out if they don’t work.

   So we end up with COE documents like this one that attempt to avoid bias buy not saying a OS is required. But due to no interoperability testing do ...

   ... enforce a OS by stealth.

   Of course John Sheridan will fear being fired for suggesting something that is new ground. So new ground will never get explored properly. So Australian Government IT is like China after the destroyed the star fleet and closed. Slowly going from being from advanced and good to obsolete and out of date and secuirty risky.

   This is not a presume. John Sheridan does not have the interoperability test data to back what is written in the COE that is is really cross platform supporting.

   Basically John Sheridan if you cannot present a COE with proper interoperability test data you will be ripped to shreds over and over again.

   Linux Conference Australia will be in Canberra 2013 it will be a very good time to have you house in order to talk to the Linux World about exactly what the Australian government wants from them.

   You have under 11 months to get your house in order.

   GD Star Rating
   loading...
10. Rod Limerick - AGIMO says:

    March 22, 2012 at 11:44 am

    Documents have been updated to correct ECMA edition references.

    Rod
    AGIMO Blog Admin

    GD Star Rating
    loading...
11. Nathan Watson - AGIMO says:

    September 24, 2012 at 11:43 am

    Comments on this post are now closed. Please let us know if you would like to discuss this post.

    For further information on the review of the Common Operating Environment Policy, please see the latest post.

    Nathan
    AGIMO Blog Admin

    GD Star Rating
    loading...