There’s no shortage of people out there willing to give you security advice. But the best advice comes from the IT pros on the ground waging the war on insecurity. Here are five tips to improve your security posture.
1. Look at Layer 7 firewalls
“Definitely look at your existing firewall infrastructure and start considering Layer 7 firewalls that are application-aware,” said Alfred Ng, director of IT for the Edmonton Oilers Hockey Club.
Application layer firewalls are also important for blocking certain functionalities within instant messaging applications, which a lot of companies either just block or allow, said Ng. “If you are using Yahoo Messenger or Google Talk, you can send those instant messages, but [it] can prevent you from transferring files or doing any video conferencing that might consume more bandwidth than what you want,” he said.
Traditional firewalls no longer do the job in terms of filtering and preventing certain functionalities for end users, according to Ng, especially with the proliferation of social media. “In our environment, deploying a Layer 7 application firewall really helps,” he said.
2. Use two-factor authentication
Ng also recommends making sure that all externally accessible Web sites or applications are secure using two-factor authentication.
User passwords are “pretty easy to acquire” and user names are easy to guess because they are usually related to the user’s e-mail address, said Ng. “With two-factor authentication, you are able to provide another layer of security and really identify who has the right to access information,” he said.
This could include a hardware token, for example, with a token code that changes every thirty seconds, he said. “We are getting into fingerprint and facial recognition as well,” he said.
Facial features and retinal features “are unique to everybody,” which helps safeguard against identity theft, he said. “Identify theft is growing and growing. It’s good to take the means to protect your sensitive data … peers that I talk to are taking more and more measures to increase their authentication methods into their environments,” said Ng.
3. Password hygiene
While your employees probably despise the practice, requiring a password change every 60 or 90 days is a standard practice at most organizations — and for good reason. Password expiry dates limit the amount of time that a log-in can be cracked/brute forced by a hacker.
Brian Bourne, founder of the annual SecTor security conference in Toronto, said the sweet spot is 90 to 120 days because it will limit the backlash from annoyed employees.
Frequent changes, he said, usually mean users will opt for a “Password01, Password02, Password03” routine, which defeats the purpose of the change.
For Microsoft shops, using Active Directory to enable password complexity requirements, set minimum password length and enforce password history are all considered best practices.
Brian O’Higgins, an independent Ottawa-based security analyst, agreed with Bourne, but warned that rules to enforce password length, non-dictionary words, roll-over time, repeated characters can be abused with too much enthusiasm and often do more harm than good.
“Another area to watch is the password auto recovery system,” he said. “These are often the weak point as the challenge or response can result in something much more guessable.”
Other policy tips include confirming a password change back to the user to help in detecting potentially hijacked accounts, and not offering hints that a password was incorrect.
For setting a threshold for account lockouts, Bourne advised organizations pick a low enough number that it doesn’t allow an attacker to get very far in their attack, but a high enough number so it lets a real user “butterfinger” their password enough times to get it right.
“Ten to 15 is my favoured range,” he said.
“One of the big problems with organizations is that it is hard for them to understand what the real risk is related with making a particular choice, so then we get overly concerned about something because it appears scarier,” said Diana Kelley, partner at IT security consultancy SecurityCurve. “Be realistic about risk,” she said.
Kelley suggests “sitting down and taking the emotions out of it and looking at it from a quantified, reasonable perspective” to determine what the real risk is to the organization. For example, an externally facing Web site may “appear scarier” than an internal threat, which might actually be the bigger problem, she said.
4. Talk in a language the business understands
It’s one thing for techies to warn each other about buffers or an SQL injection vulnerability, but most of the time, this doesn’t make sense to a business unit owner or an executive, said Kelley.
Kelley recommends IT adjusts its language when speaking security to non-IT units and take the conversation “outside of the techie realm” to focus on what the risk means for the business.
“There’s an underlying technical reason, but as the business itself, what does that mean,” she said.
“What they need to hear is, ‘Our customer data is at risk, we have a high likelihood of it being exposed because the problem is easy to exploit, it’s available from outside the company … in order to fix it, it will cost us this much time and this much in terms of resources,’” said Kelley.
5. Test security before going live
All too often, technologies in the health-care industry get developed and implemented with little thought to security, thinks the chief information officer with Toronto-based Hospital for Sick Children.
It’s with very good reason that development of health-care IT systems is focused on providing adequate functionality in the tools, said Daniela Crivianu-Gaita. But building for factors like ease of use and patient safety are hardly enough, she said.
“There isn’t too much being done during the implementation in terms of being able to test fully the implementation of the system,” said Crivianu-Gaita.
Important security questions only get asked when it’s too late after the application has gone live, said Crivianu-Gaita.
At The Hospital for Sick Children, security is carefully incorporated into system development and implementation, with testing procedures for various components, she said.
One such security capability that is rigorously tested at the hospital is role-based access.
“You have different roles for users so you really must test all the different possible roles,” said Crivianu-Gaita. “Is it doing what you assume it will be doing?”
Another example, is vulnerability testing applied to Web-based applications at the hospital.
But in general, the practice at The Hospital for Sick Children is to perform a full disaster recovery test before any system goes live. During the test, disasters are simulated and the system is re-built from scratch.
“We need to be able to do it successfully and without any loss of data,” said Crivianu-Gaita.
But it was nonetheless a learning process for The Hospital for Sick Children. They, too, used to treat security as an afterthought, recalls Crivianu-Gaita. Fortunately, for the hospital, the consequences were minor but the lesson was to always be proactive about security.
“Those small issues were enough for us to realize we were just lucky that nothing major happened,” said Crivianu-Gaita.
