Ministry of Social Development - a study in security architecture and governance failure

Matthew Hackling

Matthew has over ten years experience operating solely in the area of information security, holds a Bachelors degree in security management from ECU and is also a CISSP. He is a former Account Director in Deloitte’s Security & Privacy Services practice. Matthew has led security testing teams on assessments of large core systems replacement projects for banking institutions. He operates more in the area of information security governance these days, despite his urges still stay a bit technical. Hence he plays with backtrack linux, metasploit and new web application security assessment tools in his rare free time. Currently he runs his own consultancy called Ronin Security Consulting and holds the title of General Manager of Security Testing at Enex TestLab. He is an active member of the Australian Information Security Association, and held the office of Melbourne Branch Executive for a number of years. Matt’s security blog is called Infamous Agenda and he is an active twitter user with the handle @mhackling

In case you haven't heard, a high profile blogger acting on a tip off identified that pretty much complete access was available to all the internal file shares on the corporate network of New Zealand's Ministry of Social Development (MSD) via their public access kiosk computers. Other interesting facts have come to light such as that vulnerabilities were reported in a penetration test and not acted upon.

Firstly let's think about the security architectural failures here.

1. There was no network segregation between the kiosks and the greater MSD network. This may indicate a lack of understanding of the requirement for and use of a security "zone model"

2. Some of the most sensitive data available to MSD was stored on open file shares. This may indicate a lack of understanding of the "principle of least privilege"

3. Virtualisation snapshots of servers were also available on open file shares, allowing an attacker to potentially "takeaway" internal servers to crack into their contents. This may indicate a lack of security considerations around backup data.

Secondly, let's think about the security governance failures.

1. A penetration test report was commissioned from a third party (Dimension Data) but recommendations were not acted upon. This indicates that either the risks identified were not actively tracked in a risk register, or that risk was accepted without treatment due to a misunderstanding of the context of the risks. If we use some "black hat thinking" to coin DeBono, it is possible that the report was "locked in the bottom drawer" and conveniently forgotten about by a project manager or similar functionary, who would be personally impacted by a budget overrun.

2. No information classification scheme was applied. It is normal for "normal organisational data" to not be labelled, but the most important data in the organisation should be classified. For example locations and details of "at risk" children should be classified and highly restricted.

3. Security controls were not applied commensurate to the security classification of the data. It would make sense to encrypt and password protect such sensitive data as well as storing it on restricted file shares.

If you think this was bad, imagine what a "black hat" could have done with a boot CD or USB of the backtrack security testing operating system in one of those public access kiosks...obviously some people at MSD can't.

Follow @CSO_Australia and sign up to the CSO Australia newsletter.

Tags: Development, social, of, (MSD), Ministry