Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

What security pros can learn from the networking team

Josh Fruhlinger | July 1, 2016
You might find dealing with the networking side frustrating—but they have a lot to teach you

Make nice with the biz side

If your security team is tired of butting heads with corporate higher ups, they might want to talk to network staff to learn how to maneuver through the hierarchy to get things done. "Now that security is a board-level issue at companies, security people can also learn lessons from network people about getting along with the business side," says Bomgar's Schorr. "When all businesses were going online, that was pretty revolutionary, and network people had to deal with the business in doing that. Security now needs to learn the language of the business like network people did years ago."

Network teams have the data

If you do suffer a security breach, your network teammates should be the first people you turn to for data. "What many security pros may not realize is that network engineers are often collecting-or at least have the systems in place to collect-all of the data traversing the network, down to the individual packets," says Jay Botelho, director of product management at Savvius. "This information is extremely useful to security teams both when analyzing incoming alerts, and when investigating a breach that may not have been picked up because it was reported as a low-severity alert."

"Tools like netflow can keep historical data on traffic entering and exiting the network, including timestamps," adds Radware Security Evangelist Ron Winward. "SNMP graphs are useful for tracking the destination of volumetric attacks inside of a network."

Training, training, training

Your security teams should be trained on relevant networking technology from day one. "As a former network architect, I know what it's like to be told 'make it secure' by a non-network person," says Sean Cordero, senior executive director, Office of the CISO at Optiv Security. "Due to their lack of technical understanding, this person may not realize that the change could be a multi-week or -month effort just to get the appropriate changes, communications, and testing done. Comments like this from underinformed security personnel can be easily interpreted as ignorant or ill-informed, which poisons the well of credibility for the security team."

Know your history

One thing to keep in mind is that many of the networks and network tools you're protecting are old and long established. "Many security products that have been deployed over the last 10 years are relatively new, immature products, as compared to the networks that they work alongside," says Brian Molinari, national practice director for infrastructure services atOpenSky. "This means that often, things like management have taken a backseat to getting the product out the door. Security products break. Network gets blamed."

Goals in conflict

It can help just to be mindful of the fact that different internal teams might have different motivations and incentives. "A key flaw that causes so many organizational conflicts is that teams are measured on goals that are seen as orthogonal to each other," says Andrew Storms, vice president of security services for New Context. "Security is focused on reducing risk. Ops wants to ensure stability and uptime. The dev team wants to get code to the customer sooner. Everyone is inherently working at cross purposes, even though ultimately the organization has the same big-picture goal. I've seen this conflict escalate to the point that a department has secured budget for firewalls to block other departments from gaining access." Trying to understand what other groups within your company are being told higher-ups to do can help mitigate conflict.

 

Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.