Network security doesn't have to be expensive, and it doesn't have to be complicated. Yes, there are lots of excellent products, service and consultants ready to help improve your network security, and yet that shouldn't be the first place an organization goes to prepare against hackers, insider threats, data loss and malware. Fancy new technologies won't help if you're not focusing on the roots of good cybersecurity. Let's talk about some of the most important questions that people rarely ask about cybersecurity, perhaps because they seem so simplistic.
We all know that it doesn't matter how good a home security system is if someone leaves the garage door open overnight — and a pricey car alarm doesn't help if the keys and clicker are left in the ignition, and the car window's open.
Here are four questions that reflect a foundation of security management. Your answers may help set the foundation of a solid security posture.
1. Are the network's security policies up to date?
Creating a a comprehensive security policy can be a nightmare. Endless meetings with stakeholders. Wheeling and dealing between IT and line-of-business management. Striking and re-striking the fine line between approving a policy that's overly broad, and specifying so many minute details that the policy becomes too hard to implement. Not only that, but there are pressures to make policies as broad as possible to provide the least inconvenience to employees (and their managers who don't have patience for such matters).
Like someone who buys a snazzy new smartphone only to see its twice-as-cool replacement announced the next day, once security policies are finished, those policies are almost immediately out of date.
Applications become decommissioned – and yet the application's access ports remain active. New use cases are brought before the IT department. New on-premise applications go online, while some line-of-business departments write shadow contracts with cloud services providers. Are those covered by the security policy? Painful though it may be, security policies must be kept up to date, not only through regular reviews, but also by a process of actively amending the policy before security configurations are changed.
2. Are security configuration changes driven by security policy?
Continuing in that vein, there are myriad areas where security-related configuration changes are applied on a network. Firewalls and Intrusion Detection/Prevention Systems (IDPS) like those from Cisco or Wedge Networks are one area; change management systems like those from AlgoSec or Firemon are another.
There's more to network security, though, than firewalls. Organizations need to configure policies on servers like Oracle or Microsoft Exchange; identity systems including Firebase or Okta; network routers and Wi-Fi access points; Virtual Private Network (VPN) servers, cloud-based applications like HubSpot or Salesforce.com; and of course, on-premises file and application servers.
Beyond routine moves, adds and changes to accommodate new employees or projects, changes to security settings in any of those areas should be policy-driven. When an application comes online, goes offline, or moves to another security zone on the network, the first step should be to document it within the security policy, while checking for conflicts or contradiction. Then, and only then, once changes to the policy are understood and approved, should administrators be allowed to make changes to firewalls, access control lists, Virtual LAN (VLAN) configurations, and so-on.
3. Is automation doing the heavy lifting for repetitive and sensitive tasks?
OK, say the network access security policy has been updated for new applications, and the changes are approved. Whoops — an administrator charged with implementing the necessary changes in 23 firewalls made a goof with one of them. Maybe the wrong rule was changed. Perhaps the right rule was changed but incorrectly. Either way, there will be consequences.
One consequence might be that an application fails or users are not able to access critical applications. It may take some time to find the root cause of that trouble ticket, but ultimately the problem will be resolved. A more severe consequence might be new security vulnerability that might leak data or allow network penetration. You may never find that error.
The solution: automation. By using automated tools to implement security policy changes across hardware, software and infrastructure, you have much greater assurance that the correct changes have been made. Not only can administrators review logs to ensure that every change has been implemented correctly, but the automation package can signal when a change has failed. In many cases, the automation system can periodically compare device settings against the security policy, document where there is a deviation from the policy, and then remediate the situation. Through automation, policy truly can drive security implementation.
4. Is somebody watching the watchers?
Accidental misconfiguration of security settings on firewalls, routers, and application servers can be costly, especially if they introduce an unexpected security vulnerability. What if the misconfigurations aren't accidental? While I'm not casting aspersions on your IT staff, it's not difficult for a skilled administrator to open a back door into a network. That's risk nobody can afford.
One of the best solutions, as mentioned above, is automation. If humans aren't allowed to manually change security parameters or even touch the settings directly, it's much more difficult to make harmful mistakes or sabotage network defenses. Still, malicious users with escalated administrative privileges can still cause mischief.
What's needed: Tamper-proof logging of all changes to hardware, software and security profiles, with the logs locked away from all administrators with permissions to make network changes. After all, we don't want someone changing or deleting logs. Another active approach is to set up alerts to upper management whenever security permissions are changed, so that they can respond immediately if such changes are not authorized. In this case, transparency is the best policy.
And the answer is….?
In the never-ending quest for a more secure network, it's enticing to keep looking to new tools and technologies. Certainly we need cutting-edge resources to deter DDoS attacks, determined hackers, and insider data theft. That's only part of the story — the other part is to make sure that our security policies and IT teams are taking care of the fundamentals. Before you send out the next RFP to a security consultant, make sure that you've answered those four questions first.
This article is published as part of the IDG Contributor Network. Want to Join?