Filling day-to-day gaps
That's exactly what Miller is trying to avoid. The Bank of Labor maintains an information security policy that addresses high-level issues, including the bank's overall stance on security and broad rules, such as a mandate requiring employees to use passwords to access data. The policies, which are put in place only after board approval, don't get into the weeds of the technology or spell out details such as the exact character requirements for passwords (which might change over time, anyway).
The purpose of our policies is to be at a high level, not to cover every eventuality out there.—Shaun Miller, information security officer, Bank of Labor
To complement the broad policies, Miller's group regularly modifies rules to tackle current security gaps. Most recently, the security team blocked the use of Flash software because of its well-publicized vulnerabilities, and because it's rarely used in business-related websites anymore. "We don't consider that a change to policy," Miller says. "Our board of directors approves policy, and they don't know what Flash is or what it does. It's just an example of a simple, day-to-day business response to threats as needed."
To keep people in the loop about updates, Miller sends email messages announcing changes and explaining why they're important. Saying he often includes links to background information, Miller explains that making sure people understand why the changes are necessary and being clear about the risks has been instrumental in preventing user frustration and ensuring that employees are willing to comply with even with small policy changes.
Test, test, test
Devin Meade, senior systems manager in charge of security at Frankfurt Short Bruza (FSB), says he prefers to keep security policy fluid because the architectural engineering planning firm is relatively small (it has 150 users) and because it isn't directly affected by regulatory requirements. While FSB does have a formal security policy that is approved by the board of directors, Meade and his team make frequent recommendations for new procedures, using a small steering committee of about a half-dozen users to solicit feedback before rolling out the changes to a wider user audience.
"Our standard way of doing patches or making changes to our security stance is to test them out on a machine to see how they work and to roll them out to a representative group of people," he explains. That steering committee then tests the changes to determine what will work and what won't for FSB's users.
For example, Meade and his team recommended bumping up encryption. But during the steering committee's tests, the changes were found to make VPN access too unstable and slow, so Meade's team went back to the drawing board. It was a similar story when the team tried to enforce URL whitelisting and blacklisting to restrict user access to certain "not safe for work" sites. That move, Meade says, didn't work out as anticipated because the technology involved wasn't mature enough at the time.
Sign up for CIO Asia eNewsletters.