How an auditor worked with federal IT to check security controls

Auditing federal IT systems doesn’t have to be chaotic.

In fact, for Gerald Auger, a former cybersecurity auditor for public sector systems, the week-long checklist efforts involved little tension or shock for the auditees. Because everybody knew he was coming.

“I’ve never been part of a surprise audit,” Auger told IT Brew.

Auger, now adjunct faculty at military college The Citadel and CEO of his consulting firm Coastal Information Security Group, used to validate cybersecurity practices of federal systems, as mandated by the Federal Information Security Modernization Act of 2002.

Such audits required Auger and his team to check federal systems and assess the implementation of security controls found and categorized in the playbook NIST 800-53. The former professional services contractor with Booz Allen Hamilton and Honeywell shared with us how he interacted with in-house IT teams to perform the cybersecurity checks.

The cooperative process involves liaisons, dummy accounts, request forms, junior auditors, and few surprises.

Meet the liaison. An audit, Auger said, frequently requires an in-house sponsor—often a program manager or information security leader who is CC’d on emails and facilitates communication between the audit team and the IT folks supplying the needed access, “dummy” accounts, and read-only restrictions. A contact person prevents the “nightmare scenario,” he told us, of an auditor emailing an IT staff asking for access.

About that access. Every system has an administrator, application owner, or help-desk pro who can distribute credentials, but an auditor often has to ask for access through a formal web or email request in advance.

The auditor’s arrival should be an extension of role-based access control, Auger told us. Like an employee, the auditor should only have access to necessary data sources required for the job. Which means defining scope.

Scope. A key element to an audit, Auger said, is determining what an auditor is authorized to access. He used the example of a port. A Federal Information Security Management Act (FISMA) auditor may have to check the cargo-tracking system for security controls, beginning with broad questions that ultimately determine in-scope technologies.

Is there least privilege? Do systems only run essential services? Where are the backups? A port system’s SQL database may connect to Active Directory; an auditor then may need to see the AD environment to confirm role-based access. An auditor similarly may require a look at a software-portability service like Veeam to see how backups are scheduled.

That kind of access requires specialized expertise, Auger added. “There’s no way you would want someone who’s not qualified to use a technology like that inside poking around. It just doesn’t happen,” he said.

So, when does an audit become a breach? “​​The only way it would really happen is if an auditor, with their access, technically accessed a system or data set that they didn’t have a need to access, and saw data,” Auger told us.

Auger said he frequently had an in-house attendant with him during an audit, often the liaison. “By virtue of that physical presence, you’re not going to really be able to, like, stick a thumb drive in something random and pull something out,” he said.

His audit teams frequently featured “junior” auditors, often newer to the field. Most groups have at least one senior person who can mentor and provide insights, according to Auger; all received clearance and authorization from government officials to access a system.

Auger said he had never felt a tense atmosphere during a federal-systems check, partly because the audits were no surprise, requiring four to six weeks of advanced planning. An audit is well-structured, and its auditors receive authorization and top-level support, he told us.

“You never show up and then try to figure it out. That’s a nightmare. That’s a terrible nightmare.”