Whole of Government Common Operating Environment Discussion Paper

Common Operating Environment

Introduction/Background

1. To drive greater efficiency and transparency across Australian Government operations, the government has established a coordinated procurement contracting framework to deliver efficiencies and savings from goods and services in common use by Australian Government Departments and Agencies subject to the Financial Management and Accountability Act (FMA Act 1997).
2. The Whole of Government (WofG) Common Operating Environment (COE) was identified by the Desktop Scoping Study (Recommendation 2) as a critical element in driving future savings in services provisioning and increasing the flexibility and responsiveness of government operations.
3. In October 2009, the Government agreed to the development of a Whole of Government Common Operating Environment Policy.   This policy is expected to:
   • Optimise the number of desktop Standard Operating Environments (SOE) consistent with meeting the Government’s business objectives;
   • Improve Agency ability to share services and applications; and
   • Support the Government’s e-Security Policy.
4. On October 16, 2009, the Secretaries ICT Governance Board (SIGB) approved the ICT Customisation and Bespoke Development Policy, which strengthens the governance of customised and bespoke development.  This policy is expected to:
   • Reduce the percentage of customised and bespoke solutions across government;
   • Leverage current and future investment in government and commercial off-the-shelf solutions; and
   • Increase opportunities to standardise government business processes and systems.
5. The WofG COE Policy complements the ICT Customisation and Bespoke Development Policy by standardising and decreasing the number of desktop operating environments to be supported across Government.  As of June 2010 there are a minimum of 186 separate SOE images built with different components, standards and technologies.

Goals

6. The goals of this policy are:
7. Optimise the number of desktop SOE
   Consistent with meeting the Government’s business objectives, by defining common standards in hardware and software the number of SOE images required to support the business needs of government agencies will be reduced. In turn this will reduce the costs for SOE development and maintenance.
8. Support the Government’s e-Security Policy
   The COE will mandate a common security configuration to be used across agencies; this will improve the level of security across agency networks. Industry partners will be provided with these standards making application design easier, more compatible across agencies and inherently more secure.
9. Improve Agency ability to share services and applications
   By using the agreed common standards and defining common packaging methods, agencies will be able to share services readily and reduce the need for duplication. Lead agencies will be in a position to implement an application or service, which can then be reused across other government agencies.
10. The COE will enable Agencies to respond more quickly to changing technology cycles, facilitating easier, more cost-effective upgrades and supporting a move to more rapid adoption cycles, enhancing Agency and Government agility.

Principles

11. The principles can be described as the basic way in which the COE will work. The principles relate to the goals of the policy, they are enduring and will not be modified as technology changes.
12. As the COE policy is complimentary to other policies so are the principles.  Other principles used by the COE are defined by the cross agency services architecture principles and the Australian Government principles for the reuse of software and other ICT assets. Specific principles for the COE are.
13. Common and agreed standards
    The COE will be based on common standards; where practical the standards will be based on open standards. These standards will facilitate reuse of standard components and transportability of resources. These standards can be applied across the COE regardless of the delivery mechanism.
14. Meets agency business requirements
    The COE must be flexible enough to meet the requirements of the agencies. It will be capable of supporting multiple unique SOE’s however the need for a unique SOE will be driven by the business requirement.
15. Secure
    The COE must be secure on all levels providing, confidentiality, integrity and availability. Any procedures defined by the COE must have clear accountability and an ability to be audited.
16. Supportable
    All components used must be supportable to ensure the COE remains reliable and stable. Support must be readily available and cost efficient. The skillset used to provide the support must ready available.
17. Complies with legislative requirementsThe COE will comply with all relevant legislative requirements.

Composition

18. The WofG Common Operating Environment is to be based on the principles.  The use of common standards promotes interoperability, provides common functionality and supports a consistent user experience. These standards will be applied to all users regardless of how the desktop environment is delivered. e.g. Desktop, thin-client or desktop virtualisation.
19. The COE may be supported by multiple SOEs.  The COE policy defines the principles and standards while the SOE defines the solutions and technologies.





20. A SOE is a specific solution based on the COE. It is comprised of an operating system, core services, a standard application set, a defined security configuration and a defined user configuration.



21. The System is defined as the layer of the SOE that the end user does not directly interact with or is aware of but is used to support the layers above such as the core services and standard applications.
22. Core services are services which are exposed to the user to perform a function but does not manipulate or modify the user’s data.
23. Standard applications are generic applications which can be used to view, manipulate or save data.
24. Agency specific applications are used to deliver specific business outcomes. Agencies are responsible for the licensing and maintenance of these applications as they are not considered part of the COE.

Standards

The standards are based on are an aggregate of technologies currently used by agencies covered under the FMA Act.

Common Operating Environment Standards

Category	Description
Security configuration	Confidentiality (also known as secrecy), meaning that the computing system’s assets can be read only by authorised parties.Integrity, meaning that the assets can only be modified or deleted by authorised parties in authorized ways. Availability, meaning that the assets are accessible to the authorised parties in a timely manner (as determined by the systems requirements). The configuration must be endorsed by DSD
User configuration	Must support a consistent user experience regardless of the delivery mechanism.All configurations should be in line with the operating systems defined best practice Access to data should done with the use of links to a UNC with reference to mapped networked drives to be avoided The interface should be minimal to reduce the impact on system performance
Hardware	All hardware to comply with minimum specifications as outlined by the Desktop Hardware panel
Network	Must support WofG Internet Protocol (IP) policy
Operating System	The operating system must be procured in accordance Commonwealth Procurement guidelines and in accordance with the COTS\GOTS policy.Must be capable of supporting the principles outlined in this policy. Patches for the OS must be able to be deployed remotely without interaction from end users.
Storage	Must be able to be backed upMust be secured Portable storage must be encrypted in a manner that is integrated with the Operating System
Application frameworks	Must be in vendor supportMust comply with application management as defined by this policy
Codecs	The following Codecs are endorsed for useVideo: MPEG-1, MPEG-2, MPEG-4, MJPEG, DV,WMV, RM, DivX, Sorenson 3, QuickTime 6, WMV9 Audio: WMA, MP3, AAC, AC-3, Vorbis
Antivirus	Must support remote automated deliveryMust not rely only pattern based detection methods
Firewall	Must prevent inbound and outbound connectionsMust be centrally managed Must prevent end users stopping the service
Encryption	At minimum must have AES encryption with a 128 bit key
USB Control	Must support remote automated deliveryMust support central configuration
Message Classification	Must support remote automated deliveryMust support Australian Email Protective Marking Standard
File compression utility	Must be compatible with the Zip file format and the standard as outlined by PKware
Multimedia viewer	Must be capable of supporting at least one of the endorsed Codecs
Web Browser	Must be able to be centrally managed and configuredMust not allow end user customisation and unauthorised add-ins
Office productivity	Must support the Open Office XML file format as defined by ECMA-376 and ISO/IEC 29500

Application Management

25. In order to support the principles of common standards and having a supportable environment, management of the applications used as part of the COE will need to be addressed.
26. To maintain consistency and reduce complexity, all applications used as part the COE (The System, Core services and Standard applications) must be the current and supported version (known as N) or its immediate predecessor (known as N-1). N refers to the major version of an application, e.g. version 7.x is N, version 6.0 or 6.1 are N-1. This will ensure all applications are supported and by allowing the N-1 version gives the agency flexibility to plan required upgrades.
27. Support for legacy applications which will not work natively with the COE may be delivered by a form of virtualisation. The form of virtualisation best suited to the agency will be dependent on factors such as the infrastructure available and the network bandwidth.

Virtualisation of Legacy Applications

Virtualisation on the desktop	Application virtualisation	Session virtualisation
The client operating system runs a virtualization application that hosts Virtual Machine(s).	An application is isolated from the underlying operating system by means of wrapper software that encapsulates it.	Only the presentation information is sent between the client and the host systems.
Used to run one or a limited number of legacy applications on a legacy operating system. Suitable where limited infrastructure and support is available for virtualisation.	Eliminates application coexistence issues as well as improving automation and streamlining. The applications are cached and executed on the client system.	Used to provide access to a legacy application to a large number of users.Currently the most widely used form of virtualisation across the agencies.

28. As the agencies converge on the COE standards over time it is expected that the need for the virtualisation of legacy applications will be reduced.

Green ICT Considerations

29. The COE will support the Green ICT guidance list as endorsed by the Chief Information Officer Committee (CIOC) on 7 April 2009. All SOE images built in accordance with the COE policy must implement the relevant configuration settings as outlined in the Green ICT guidance list.

Software Packaging

30. In support of the goal of agencies being able share services the packaging of software will be standardised so an application can be packaged once and reused many times across agencies.
31. Software will be available by a minimal number of distribution methods, and where possible will be included on the base image provided to Endorsed Suppliers for delivery with new hardware.
32. Current practices suggest that wrapped MSI packages will form the standard for current delivery mechanisms. However as the use of streaming virtualised applications increases, standards will need to be developed to ensure that these technologies can be standardised to promote the reuse packaged virtual applications between agencies.

Security and User Configurations

33. Recommended settings for the operating system, web browser and Office suite will be based on the settings specified by United States Government Configuration Baseline (USGCB) and the vendor’s best practice recommendations. The configuration settings will also be endorsed by DSD.

Governance

Compliance

34. This Policy applies to all FMA Act Agencies, and is also available to Commonwealth Authority and Companies (CAC) Act Agencies and the States and Territories.
35. Section 44(1) of the Financial Management and Accountability Act 1997 (FMA Act) requires all Government Departments to use available resources in an efficient, effective and ethical manner.
36. This policy is supported by  the ICT Customisation and Bespoke Development Policy and addresses requirement  1 of the governance requirements as identified in schedule 1 of the overarching policy:

“ The areas where commercial and government off-the-shelf solutions are preferred to customised or bespoke solutions must be defined.

The agency executive board will approve the defined areas that apply at agency level.  Agency executive board approval is required for any proposed ICT customisation or bespoke development at agency level.

The SIGB will approve the defined areas that apply at cross-agency and/or whole-of-government level.  These arrangements will be subject to the Process for Administration of Opt-Outs from Whole-of-Government Arrangements. “

Understanding and Complying with the WofG COE Policy

37. It is the responsibility of all FMA Act Agencies to ensure they understand and comply with this Policy.
38. COE Policy compliance activities are expected to occur in conjunction with the stream activities identified in the COTS/GOTS Policy.   Stream 2 is of particular relevance and identifies the “selection and agreement of whole-of-government off-the-shelf solutions” commencing in January 2010, and then being an ongoing activity.   Implementation of the COE Policy is expected to occur in conjunction with hardware fleet refresh activities; however Agencies may initiate sooner.  Stream 3 of the COTS/GOTS Policy references “Policy measurement and review” with an initial report due by December 2010.  COE Policy reporting will be done in conjunction with the COTS/GOTS Policy reporting, with reporting metrics for COE Policy compliance being incorporated into AGIMO annual benchmark reporting.
39. Compliance of the Core Configuration Settings will be monitored by commercially available SCAP toolsets with results incorporated into the AGIMO annual benchmark reporting.

Opt Out

40. This policy is subject to the Process for Administration of Opt-outs from Whole-of-Government Arrangements as agreed by SIGB in February 2009.  In short, the Government has directed that:
    • To seek an opt-out an agency will need to prepare a short business case based on a genuine business need, irrespective of how the driver for the opt-out is funded; and
    • The ERC’s consideration of opt-out requests is to be informed by the Secretaries’ ICT Governance Board (SIGB).
41. Initial opt-out considerations will be factored into the transition plan and are expected to show how alignment to the policy will be achieved as part of the transition plan.
42. When seeking an opt-out an agency will need to include a remediation plan to detail how it will return to the WofG COE.  Opt-outs are limited to a maximum of 3 years, after which the original business case will be reassessed to ensure it is still valid.
43. While it is recognised that agencies may have a need to develop separate SOE images, it is expected that these images will comply with the standards set out for the COE to ensure that agencies can still share data and services in a seamless manner.

Exemptions for Scientific and research purposes

44. Requests for opt-outs for Scientific or research purposes will need to show that the system requires a special configuration for a specific device or application directly related to the research task, which cannot be accommodated by the COE.
45. These modifications to these systems are to be minimal and only deviate from the COE to the extent required to make the device or application functional.
46. The criteria and process for the opt-out of systems for research purposes are to be determined by the policy working group.

COE\SOE Review Cycle

47. The COE standards will be reviewed annually, starting with a call for change requests from participating agencies in July each year. Request for changes can be based on business or technology requirements.
48. This will be followed by a two month review period of the requested changes starting in August. The review will be lead by AGIMO and supported by members of the COE working group.
49. The COE standards and the WofG SOE will then be revised from October with a release date accepted changes in December.
50. There should be no need for more than one major update of any agency specific SOE each year.
51. SOE images should be archived for a period of X years from the release date.

Roles and Responsibilities in relation to the COE Policy

52. AGIMO:
    • The creation of the initial COE policy in consultation with the COE WG. The policy will define the standards which all government SOE images must comply.
    • The standards will be reviewed on annual basis with a two month consultation period to ensure all agencies are able to request changes.
    • COE policy transition plan for the WofG SOE.
    • Where it is consistent with Agency responsibilities, AGIMO will be responsible for software licensing for products listed in the Standard Operating Environment.
53. COE Working group
    • Defining the COE standards
    • Approving the software to be used in the SOE images.
54. Government Agencies:
    • Ensuring business specific applications work within the specifications of the COE.
    • Ensuring policy compliance is maintained on their networks.
    • Initiating an Opt Out request where appropriate.
    • Security Audits to ensure all agency sponsored SOE are compliant with the relevant standards.
55. SIGB/CIOC
    • Endorsing and approving the COE policy and associated standards.
56. DSD
    • Endorse SOE security configuration and ongoing changes to the baseline.
57. SOE Lead Agency
    • Maintaining the Documentation set for the WofG SOE image
    • Design, test and build of the WofG SOE image ensuring it complies with COE standards.
    • Reviewing and maintaining the WofG SOE image.
    • Monitor the performance of the SOE image.
    • Testing on recommended hardware specifications as defined by the Desktop Hardware procurement panel. (The SOE software will not be certified as suitable for use on hardware which is not procured via this panel.)
    • Programming of changes to the SOE

Policy Implementation

58. COE Policy compliance activities are expected to occur in conjunction with fleet refresh activities however may be initiated sooner.