back to article ATO, Dept of Immigration wrist-slapped for failing security audit, again

At least two Australian government departments, the Department of Immigration and Border Protection (DIPB) and the Australian Tax Office (ATO), have inadequate security, according to a parliamentary committee report published yesterday. How far behind? They haven't even managed compliance with the top four of the Australian …

  1. RudderLessIT

    My guess at which of the four is done

    Out of the four requirements: "application whitelisting, patching systems, using the latest application and operating system versions, and restricting admin privileges"

    I am choosing 'patching systems' - as this is something that the IT team can do (mostly) without impacting users.

    Sad fact is, a lot of IT leads don't like putting in strong security constraints, such as removal of local admin, due to the long, loud and constant complaints that ensue.

    What's your guess?

    1. EnviableOne Bronze badge

      Re: My guess at which of the four is done

      Got to be OS patching.

      Deploy wsus and set auto update = job done.

    2. Anonymous Coward
      Anonymous Coward

      Re: My guess at which of the four is done

      Can confirm, I've done all of these since coming in post in the past 5 years as ISO.

      Patching - easily done, requires a lot of work and in some cases organising maintenance windows with departments but it's all low impact at worse (usually) and when things to wrong IT can handle it themselves.

      Application whitelisting - we ran tools to check what was in use prior to switching to this and when we did it was OK 99.9% of the time but we had a few, usually high level folks kicking off because their daft software no longer worked, despite them having left their laptop at home for 3 months whilst we evaluated what was in use.

      OS versions - more difficult as some of our equipment needs XP, so eventually we decided to air-gap those machines until they could get the equipment updated.

      Removal of admin rights - this was the hardest as it was all political and much of the resistance came from within our own IT department surprisingly. Many applications "couldn't run without admin rights" which we then had to go on to prove they could, if our IT management hadn't been told to get it done by a certain date this would never have happened. This one really needed the backing of our chief exec and she was prepared to go nuclear with IT management if it didn't happen.

      Bottom line if senior management don't cover you, none of this will really happen. Buck stops at the top after all.

  2. CFtheNonPartisan

    My guess is restricting admin privileges enough to pass an audit. It is the only choice that involves little work. Patches do over some users because patches break or change things. Whinging about loss of admin privilege or slower turnaround for resolving simple problems is less onerous than having something fall over.

  3. Anonymous Coward
    Anonymous Coward

    restricting admin

    Easiest to implement, makes PHB non-IT class look like they are doing something and no-one gives a hoot if the techies can't patch. Saying no shows organizational power and control if the behaviour of the PHBs of my experience is any indication. Tthe techs can be blamed for the inevitable fail. Perhaps both departments, like most organizations now, are knee-deep in process clowns who are great at rulez, process, especially with SAP forms and multiple meetings of the clueless to manage the IT peons and outsourceries involved.

    However, in mitigation, the drive to virtualize everything means patching the underlying hardware, firmware, OS and virtualization technologies means upgrades and patches are a big deal. Firmware fixes are in a worse situation if the resiliency design and implementation was not done properly which recent ATO events suggest is the case.

    Insource the lot with old time mainframers as managers !!

  4. Jonbays

    Independent Audit required here

    Clearly they have been reading "yes minister" and are not going to comply merely stall. The ANAO should Audit them and if they fail to meet agreed implementation timelines then Finance need to withhold funding and restrict them from accessing any other agencies data until they can become compliant. Nothing in the top 4 is particularly hard to achieve if adequate resources are put into it and procedures are amended to support their adoption not block them. That said this is a big agency merged and mish mash of systems all in need of a savage revision back to the basics of what they need to get the job done.

  5. CentralCoasty

    Oink, oink?

    You can see where this is going.

    New contracts coming soon.... with lots of Governance and Oversight.... which means that in 4 years time when they have failed to deliver anything they can fire all the contractors and restart the projects...... Pork Barrels All Round!

  6. Anonymous Coward
    Anonymous Coward

    Ah yes... application whitelisting. The eternal problem we face too (merely trying to keep our PCI and IRAP accreditation ticking along). Linux not having a lot of alternatives here and the few it has not enjoying a lot of positive comment when researched. (Throw in distro problems, variant kernel revs and extensions and it all gets even uglier). In fact having called for it, ASD then wrote this document admitting obliquely that maybe app whitelisting was a non-starter in Linux and you could compensate in other ways. Nothing I like more than a requirement the authors know you can't meet... but you'll be held to it anyway.

  7. the Jim bloke Silver badge
    Thumb Up

    I must admit

    ..its a pleasant change to see the tax office told to "bend over"

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019