Three ways to build an open source security toolkit

Enterprises should have a diverse set of open source security tools in their arsenal. Here are three factors that can help guide them in building the right security toolkit.

It's generally a bad idea to rely on one open source security tool to help protect an enterprise. Like any open...

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.

Vertical industries

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.

To mitigate the risks of noncompliance to more acceptable levels, enterprises should consider tools that would help organizations in meeting the compliance requirements such as log analysis.

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.

Compliance requirements

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.

Next Steps

Find out why the open source security model is suffering from a lack of resources

Discover how to improve SDN security with a risk management plan

Learn how an open source security tool detected an Android app vulnerability spike

This was first published in January 2016

Dig Deeper on Open Source Security Tools and Applications

PRO+

Content

Find more PRO+ content and other member only offers, here.

Related Discussions

Judith M. Myerson asks:

How does your company build a security toolkit of open source products?

0  Responses So Far

Join the Discussion

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close