Reducing public security risks during online transactions with government agencies

The Department of Finance Archive

The content on this page and other Finance archive pages is provided to assist research and may contain references to activities or policies that have no current application. See the full archive disclaimer.

We all recognise that online services offer a convenient, efficient and accessible means to access government services.  Unfortunately, as the demand for online government services continues to grow, so too does the scale, sophistication and perpetration of cyber crime.

The Australian Government considers it essential that all Australians understand the nature of cyber risks, and take steps to appropriately secure their computers (and internet-connected devices) and to protect their identities, privacy and finances when transacting online. The Australian Government Information Management Office (AGIMO) is supporting the Australian Government’s Cyber Security Strategy by developing guidance to help Australian Government agencies reduce security risks to the public when dealing online with the government. We invite your ideas for innovative and practical approaches that could be included in this guidance. We look forward to receiving your responses. If you prefer not to make your comments public, you can email our team at Comments will remain open until 31 March 2011. You can read more about the Australian Government’s work on cyber security in the following documents:

Comments (10)

When it somes to the interface between Government and Citizens via web services, make sure the people responsible for planning, managing, designing, implementing and maintaining the services have at least casual familiarity with OWASP — — and preferably have infosec members join in the OWASP community.

There are other issues to be concerned about too, but they boil down to "don't trust the client" - where "client" is of course the hardware/software connecting to your web service, not the person using the client to access the service. Publish Government infosec standards in order to foster discussion in the technically literate section of the community, and allow the private sector to benefit from Australia's 'corporate knowledge'.

Recommendations to small and medium businesses should also include a mention of "programming defensively" for companies that implement their own web sites or client-facing services (whether Internet or VPN accessed).

The Government could encourage the creation and adoption of infosec standards acceditation. At present a large number of companies proudly display the meaningless "ISO 9001" certification (which means they keep records). We should have have a similar certification indicating that the people responsible for building web sites dealing with personal data have been trained in and audited for compliance to those standards. These standards should be advertised through the "Stay Smart Online" web site.

The standards could cover little things like "never run a web server with administrative privileges" or "don't store credit card details in a file underneath the directory structure shared by the web server" :)

The Government could ensure that any of it's electronic offerings for transactions with Government work for a range of Operating Systems including the more secure ones. For example the e-tax offering is only available for Windows.

Interesting to note that while all the focus is on how to protect public information on Government databases, there isn't too much concern about government data stored on private company databases.

ASIO has recently been alerted to an Australian company that is (was?) a supplier to departments such as DFAT, AFP, RTA, DoD, BOM, CSIRO, NSW Police and more, whose database was open to anyone on the Internet!

If you wanted a govenment department's credit card details all you needed was an IP address to log on to the database, no user authentication needed. The company's extranet was taken off line on March 13 this year, thank goodness. But who knows who has had access to the data? My comment:

As for personal information security? A joke, people post more information about themselves on Facebook and Linkedin than any gov't agency would ever need...

Personally I'd like to see government addressing the OWASP Top 10 web application security risks for all government websites and web applications.

The OWASP Top 10 Web Application Security Risks for 2010 are:
A1: Injection
A2: Cross-Site Scripting (XSS)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References
A5: Cross-Site Request Forgery (CSRF)
A6: Security Misconfiguration
A7: Insecure Cryptographic Storage
A8: Failure to Restrict URL Access
A9: Insufficient Transport Layer Protection, and
A10: Unvalidated Redirects and Forwards.

Furthermore, some of the biggest risks with web applications come from poor development processes used by 3rd party vendors who rush to get a product to market. The government should be contractually requiring all 3rd party vendors used for the development of web applications to prove that they are using a secure development lifecycle. Furthermore, government in-house development should also be using a secure development lifecycle with a strong emphasis on finding and mitigating vulnerabilities. This includes training their developers in secure coding practices and testing techniques.

Finally, I'd like to see full disclosure by government of all breaches of their web applications that could lead to the exposure of personal or commercially sensitive information.

Thanks everyone for your responses. We appreciate your contribution and will consider your views as we develop guidance for agencies. Further contributions are welcome until 31 March when this post closes.

Thanks I think this is a good initiative to try and get a better understanding for how to secure the governement sites. We have been doing this for banks with internet banking since the 90s - now with about 30% of Australian bank IB sites run by us - and the issues always come back to the basics (esp. inside jobs) - and any good ethical hacking shop can keep apace of the threats and responses that are currently in vogue. We get our systems tested 4 times a year and will always find new attacks and have to code them out. We also use captchas, scramble pads, SMS and tokens - but the application varies with the customers perception of risk and ease of use.

But I do wonder how you do it in government when you would assume that:
- at any time you must have many web services that are between 5-10 years old
- lots of departments with many Content Mgt and database systems
- varieties of budgets and skill sets (and not necessarily aligned to areas of highest threat or value)
- no simple consistent Govt ID that can be broadly used to access services.

I agree with all that the OAUTH style app would help for a consistent ID (and why not use Facebook as initial login) - but then there need to be layers based on the percieved risk. We have tried to solve this to some extent in banking by providing portals that allow systems/functions to be securely delivered (ie. by constantly and rigourously trying to harden the shell) as 'containers' (or widgets) within an overall secure platform - which then allows security to be applied at the system/function level. This means even a less secure legacy system can be delivered in a more secure way.
In govt the corrollary would be providing a secure govt 'facebook' and then allowing depts to provide apps within it to customers with any addition security they need to add. I imagine this may seem counter to many departments view of the world as the websites are focussed on their department, rather than the end 'customer' (not a critisim, just observation of approach)

Anyway, would be happy to have our security people discuss that if you want to visit Sydney sometime!



Interesting posts. I would also recommend that Government look to the financial sector for lessons that can be learnt in the development of online services.

The banks are at the forefront of managing financial fraud while being particularly careful around client usability. Competitiveness between the banks has helped evolve online services to optimise the balance between usability and security. There's plenty of experience available to draw upon to implement services that are secure but also attractive to clients for online uptake.

Some of the lessons learnt from the banking sector were applied during the AUSkey design. This resulted in a hugely successful system with client uptake beyond expectations (300,000+ AUSkeys issued so far).

This is certainly a success story, but the Internet is an evolving landscape and authentication technologies continue to move on. Recent attacks target SMS and OTP implementations that were once considered secure. The one thing you can never be in this game is complacent!

More than happy to discuss this further.


Hi Trevor,

This is a great topic for discussion, given the multitude of layers that contributions can be made to. For example, one can consider the security layer in technologies – with previous posts already covering issues such as web application technologies.

One can also talk about the policies and processes covering security from an agency/agency representative point of view – i.e. the considerations that need to apply to the way online transaction information, including personal and financial information, is being handled at an agency and agency employee/contractor/representative level. There are already some posts that cover aspects of this.

One can also talk about the public, their attitude, expectations and mindset when engaging in online transactions with government agencies. My suggestions there are that the public comes to the online transaction “place” with a well-defined mindset and expectations that have been derived from the transaction environment that the public is already using in their day-to-day activities. Banks, which have been mentioned before, and e-commerce venues such as online shops, have already shaped the expectations of the public both in terms of the standard of services they are expecting when making transactions, and also in terms of the security rigour applied to those transactions. Thus, the above comment referring to banks as a source for ideas is probably well-warranted. In addition, I would suggest that existing transaction environment also offers a glimpse into the sort of threats, exploits, scams and overall security threats that the government is likely to face as they move more and more into the online transaction space. However, the great advantage – or danger – is that government is enjoying a higher degree of trust as a party in an online transaction than many private companies. Therefore, the expectation that government can provide the right security environment for transactions is probably much higher, and the likelihood of it being targeted by undesirable elements increases as well.

I cannot profess to be able to put forward any ground breaking ideas here. However, one thing I’d submit for consideration is the idea of having a single online transaction gateway for interacting with the public (the reference to public here is to human citizens, as opposed to any systems that facilitate G2B/G2C transactions) . Whether this is implemented as a prominent “transactions” section on the website, or as a separate portal (fictional example:, it should allow a simple URL to be used for all transactions with the public. This would remove the need to click any links embedded into an email or otherwise, offering a level of protection around a whole host of attacks. If this is given enough prominence, people may used it as they do with their online banking or major online payment facility – just type the address as opposed to clicking on it. Obviously, such a single gateway offers a raft of additional benefits – including being the central point for cyber-safety education (currently, reporting fraud, etc. (currently, etc, and providing an easy, convenient entry point for transactions for the public.

I’ll put a stop here to this post. I hope the initial point – of the multitude of layers (I only mentioned 3) to be considered when addressing the security risks of online transactions – is being considered as the next stage of the consultation process shapes up. It may be useful to separate the discussion into a series of layers, as this may allow for more focused feedback too.


Totally agree with using OWASP as the definitive reference guide for web security and this is currently already defined in DSD's ISM. Reusing two factor authentication such as AUSkey is a good idea and perhaps providing an OAuth authentication service using this for customers to reuse authentication between departments. Users have too many passwords and there is merit in allowing, but not mandating, that users use their existing accounts such as Facebook for this. External authentication is probably just as strong as the user's email password and date of birth (widely known to every service provider) which is also a single point of failure. Appropriate warning need to be put there to the user however they are ultimately responsible for the security of their credentials and keeping a few secure credentials is easier that keeping lots of secure credentials.

As mentioned earlier securing the server side is only half of the problem, the side that AGIMO and DSD will issue lots of guidance to protect. The other half is the very insecure client computers that connect to government sites. Without radical changes in software liability for vulnerable software, safety ratings for software or some market disruptive force there to improve the quality the protections on the server side will extend to protecting against wholesale compromise. This kind of change in the software market is needed to improve the security of transactions with government websites.

Comments are now closed on this post. Thank you to everyone who responded here and by email. We appreciate your input and will be considering it as we develop guidance for agencies. Any further comments can be sent to

Last updated: 29 July 2016