It's generally a bad idea to rely on one open source security tool to help protect an enterprise. Like any open...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
source product, hackers can obtain the same tool, find its weaknesses and exploit them. To make it more difficult for hackers to reach their targets, enterprises should build a kit of their favorite open source security tools. Multiple tools are better because one tool's weaknesses can be overcome with other security tools; the more tools an enterprise has in its kit, the better the chance of protecting its data and not succumbing to an exposed flaw in a specific open source security program.
An open source security toolkit should include, at the least, a detection/penetration testing tool such as Metasploit Framework, a vulnerability scanner such as Nexpose, a security incident-handling program such as MozDef, a malware analysis tool like Cuckoo Sandbox, and a network monitoring utility like Nagios. To ensure they work properly and are free of vulnerabilities, security managers should test them in a testbed network separate from the production environment.
Here are three factors to consider when building an open source security toolkit.
The choice of security tools for a toolkit should be influenced by what type of organization a security manager works for and what vertical industry that organization is in. When choosing security tools, it's also useful to know what vertical industries have been hit the most with data breaches and security incidents, as well as the nature of threats the different verticals face.
The Verizon Data Breach Investigative Report 2015, for example, shows public sector organizations are the number one target for breaches and security incidents, followed by financial services, manufacturing, accommodation and retail. Smaller organizations in retail and accommodation have been breached far more often than larger ones.
A retail organization might use open source point-of sale system tools -- like SUSE Enterprise Point of Service or OpenBravo Retail -- that have their own security controls and features. OpenBravo Retail has role-based access and approval as well as POS terminal authentication. With Linux software like SUSE Enterprise Point of Service, organizations should consider other open source security tools for Linux. To stay ahead of attackers, get the latest versions of the tools and make sure they are regularly updated.
An organization often needs to meet compliance requirements of more than one regulation. If the organization fails to comply with a regulation, it will be slapped with high fees and possibly loss of business reputation. However, simply enforcing compliance policies for each regulation or standard is not enough; in order to mitigate the risks of noncompliance, enterprises should consider compliance tools such as log analysis. One favorite is OSSEC, or Open Source Host-based Intrusion Detection Security, which can check for regulatory compliance for HIPAA, Payment Card Industry Data Security Standard, the Sarbanes-Oxley Act and the Federal Information Security Management Act (FISMA). Before using OSSEC on FISMA files, start with OpenFISMA, an automation tool specifically designed to meet FISMA requirements.
Central to OSSEC is a management server, which can help an organization better manage policies on integrity checking and log analysis across multiple operating systems, including Linux, Windows, Solaris and Mac. The server sends alerts to security managers when it detects unauthorized changes to a file system or malicious behavior in the log file. Enterprises must make sure the organization fixes the problems before compliance deadlines for mandated reports.
Service-level agreement enforcement
Organizations planning to use a software as a service (SaaS) provider to oversee portions of its IT requirements should consider using a network monitoring tool to enforce service-level agreements (SLA) the organization and the provider have agreed to. Some of these tools run in the background, while some are automated. Some are manually configurable via the command window, such as Pandora FMS and PRTG Network Monitor Freeware, while others provide more accessible user interfaces.
Without a proper networking monitoring tool, an organization has no way of knowing if the service provider meets the level of service -- uptime availability guarantees -- as specified in the SLA, nor would the security managers and network administrators know how the network is performing.
With a monitoring tool, network and security managers are able to monitor network performance and use that data to measure against the agreed level of service. When performance begins to slide downward, the tool should send alerts on what actions the organization and the service provider should take. If the alert first indicates that the performance has fallen below the agreed level, the service provider should be given a prescribed period of time to fix the problem. Failure to meet the deadline may result in penalties for the provider.
The SLA should also have an exit clause. If an organization is dissatisfied with the service provider's network performance or has security concerns that aren't being addressed, it should be able to exit without hefty penalties. The exit clause should also specify the formats the provider will use to download and back up data belonging to the organization.
About the author:
Judith M. Myerson is a security and systems engineering professional that has researched and published articles on a wide range of security, risk management and Internet of Things topics. She is the author of RFID in the Supply Chain, and is CRISC (Certified in Risk and Information System Control) and a member of OPSEC and ISACA.