Audit Linux privileges now to limit compromise, escalation, and system-wide damage. Review Linux Privileges×
Moving through a network is like using a master key. If you have the key, you do not need to break any windows. On Linux, attackers usually do not "hack" their way from one computer to another. They simply log in using stolen credentials. . A login lands in the logs, and nothing stands out. The account is valid, the source looks familiar, and access is granted. A second login follows from the same account on another system. It is still valid and still uneventful. This is how lateral movement usually begins in Linux. It does not rely on breaking in. It relies on using access that already works. Unless someone is tracking how that access moves between systems, it passes as routine activity. Strengthening your Linux security posture starts here. Why Linux Attacks Are Hard to Spot The core issue is not that the activity is hidden. It is that the system has no reason to treat it as suspicious. Check How SSH and Sudo Are Being Used Linux systems are built around remote access. SSH provides a secure way to log in. Sudo allows controlled "boss" powers. The shell is the primary way to run commands. These are foundational parts of the system. When an attacker gets valid credentials, they do not need to bring in anything new. They connect through SSH the same way an administrator would. The system accepts the session because authentication worked. This is why SSH-based lateral movement is so effective . Look for Activity That Blends In With Normal Use Once access is established, the attacker operates within normal boundaries. The commands they run are not suspicious because they are part of normal system use. From a logging perspective, you see the command but not the intent. At the network level, the problem is harder. SSH traffic is encrypted. Even if you capture the connection, you cannot see what is happening inside. Every individual action looks valid. Only the broader pattern reveals that something is wrong. This creates a massive challenge for traditional network securitybecause every individual action looks valid. Only the broader pattern reveals that something is wrong. The Gap in Security Coverage The gap is often described as a lack of tools. In practice, it is missing context. Identify Where Your Security Coverage Breaks Down Many teams use EDR, or Endpoint Detection and Response. These are like security cameras that record every move a computer makes. In Linux environments, putting these cameras everywhere is difficult. Some systems are too fast and cannot handle the extra weight. Others are temporary and only exist for a short time. This creates uneven visibility. Attackers move through the areas where security monitoring is weakest. Use Existing Logs to Fill Visibility Gaps Even without EDR, Linux generates reliable logs. Authentication events record who accessed what and when. System logs capture changes in state. The limitation is not the absence of data. It is the lack of connection between data sources. Each system logs its own perspective. Without combining them, those perspectives stay isolated. Without combining them, those perspectives stay isolated. Effective threat detection requires combining them into a single timeline . What Actually Reveals Lateral Movement Lateral movement becomes visible when small inconsistencies align. The signal is weak at first, but gets stronger across patterns. Track Authentication Patterns Across Systems A user account that typically uses one system begins appearing on many hosts quickly. The source of access may also change. Instead of logging in from a known external IP, the account starts from an internal system. This suggests access has already shifted once. Time also plays a role. Activity outside working hours or in unusual sequences can indicate the behavior is not normal. Analyze Command and Privilege Escalation Behavior An attacker may use sudo to get more power. Then they run commands to explore the environment. These actions are logged but do not trigger alertsbecause they are valid. The distinction comes from how those operations are grouped. Rapid transitions between power levels and sequences that do not match typical work start to show a deviation. This is where process data reveals intent . Building Detection From What You Already Have This is where most teams stall out. The data is there, but nothing is wired together to detect movement. Pull Every SSH Login Into One Timeline Pull SSH authentication logs from every system into one place. Not a sample, not a subset, all of it. If logins are still siloed per host, you won’t see movement. You’ll just see access. Same Account Appearing Across Multiple Hosts Pick a user and follow it. Where it logs in, how often, and how quickly it appears somewhere else. Same account touching multiple hosts in a short window is one of the few reliable early signals you get in Linux environments, especially when there’s no EDR filling in the gaps. Logins That Originate From Another Server A login from an external IP is expected. A login from another server is not the same thing. When a system becomes the source of authentication, it usually means access has already shifted once, and that’s where lateral movement starts to become visible if you’re paying attention. Build Simple Sequences First Don’t overcomplicate this. Start with a basic chain. Login followed by privilege escalation, followed by a connection to another host. That pattern shows up more often than people expect, and it’s usually ignored because each step looks valid on its own, even though the sequence tells a different story once you line it up. Accounts Accessing Systems They Don’t Normally Touch You don’t need a perfect baseline. You need a clear picture of what each account typically does. Which servers an admin usually logs into, when they access them, and where they connect from. That’s the reference point you build from over time. Without that context, every login looks identical in the logs. Oncethat happens, movement between systems blends in because nothing stands out as unusual. Turning Data Into Detection Raw data does not produce alerts on its own. It needs to be structured. Why Individual Events Don’t Mean Much on Their Own Individual events rarely provide enough context. A login shows access. A network connection shows communication. When these happen in isolation, they appear normal. When they occur in a specific order across multiple systems, they describe movement. Detection logic must link events together over time to create a narrative. Lateral movement detection logic must link events together over time to create a narrative. Why Behavior Tells You More Than Signatures Signatures look for known bad files. This fails when attackers do not use any bad files. Behavioral detection focuses on what is expected. It sets a baseline for user activity and timing. When behavior shifts away from that baseline, it creates a signal. This behavioral analysis is central to finding movement when tools are missing. How Lateral Movement Typically Unfolds in Linux Environments Initial Access An account logs in from a known external IP. The credentials are valid, and the activity matches what the system expects, so nothing stands out. Access Shifts Internally Shortly after, the same account logs into another server. This time, the source is an internal system rather than the original external IP. Events Are Viewed in Isolation Each login is evaluated on its own. Both are legitimate, both succeed, and neither triggers an alert. Because there is no immediate sign of compromise, the events are treated as routine. The Pattern Only Appears Later When authentication logs are aligned by time, the sequence becomes clear. External access is followed by internal logins that begin to form a path across systems. What initially appeared to be normal activity turns out to be lateral movement. The signal was always present, but it only became visible oncethe events were connected. Why Strategy Matters More Than Tools Tools do not replace visibility. EDR provides insight into where it is placed, but it does not solve gaps in coverage. Detection depends on consistent data and the ability to analyze relationships between events. Linux requires behavioral thinking. These environments do not generate clear red flags during lateral movement. They generate normal activity used in the wrong context. Attackers succeed by staying within expected boundaries. They assume valid actions will not be questioned. Detection does not come from finding something obviously evil. It comes from recognizing when a sequence of valid actions no longer makes sense. . Learn how to detect lateral movement in Linux systems without EDR by leveraging existing logs and authentication patterns for improved security.. Lateral Movement Detection, SSH Security, Linux Authentication, Event Analysis, Security Strategy. . MaK Ulac
Linux servers are a far more dominant force in the industry than people give them credit for. Sure, many personal computers run on Windows, but Linux is the operating system behind roughly 81% of all the websites. One reason for this is that it’s more resilient to the majority of threats that most of their counterparts face. . While Linux is generally more resilient to viruses, these devices and servers almost always exist on the same network as devices using other systems. So, even though they cannot suffer the brunt of the attack, they can spread viruses and malware to other devices in the network. This is why Linux admins must learn to protect and future-proof their servers. You can’t just slap an antivirus like a flex tape and hope you’ve solved all the problems. Your approach needs to be far more holistic than that. In this article, I’ll provide tips admins can implement to secure their servers against malware, viruses, and other malicious threats. Understanding the Linux Server Security Paradigm The first thing worth pointing out is that Linux isn’t immune to all sorts of malware. Many people believe this, which is incredibly dangerous, especially when you consider that you’re not taking measures to protect yourself from a threat you don’t know exists. Ransomware may be less common on Linux than Windows, but it’s not unheard of. The number of Linux ransomware instances has increased dramatically. This is especially problematic for major financial institutions, where changes and updates are much slower than with smaller teams. There are also tools known as cryptocurrency miners, which can latch onto your system and drain resources for your use. In this case, you have an OS that’s supposed to be faster, simpler, and more reliable, and it’s anything but that. Moreover, since you’re not even aware of the severity of this threat, this is the last thing that will cross your mind during diagnostics. Lastly, you need to be aware of rootkits and stealthymalware that require kernel-level access to function. They can manipulate system calls and logs, cloaking their activity and making them incredibly hard to detect. Rootkits, which allow unauthorized entry to the kernel level of servers, require a comprehensive approach. Linux admins should employ tools explicitly designed to detect rootkits—such as Chkrootkit or rkhunter—while implementing strict kernel integrity checks to detect unapproved changes promptly. Setting tripwires that notify administrators about changes in crucial files or configurations that could indicate rootkit activity is also an effective strategy. What Is The Role of Antivirus in Linux Server Security? Most of the Internet is on Linux servers, which means that the attack surface for malicious third parties is the largest it’s ever been. Every server manager needs an elaborate guide on server antivirus software and the right platform to keep everything secure. One of the main reasons you need an antivirus for Linux is to safeguard against reckless user behavior. Think of it as a life vest for someone on a boat. You hope they won’t make a mistake, but if they do, it’s better if they’re in a vest. Servers handle a lot of sensitive data, meaning some specific use cases demand extra security on your part. This is especially true when you consider all the regulatory matters organizations face today. Advancing Beyond Antivirus: Comprehensive Security Strategies To secure the data on your server, you need to employ more holistic strategies. This is especially true if it’s company data that we’re talking about. One strategy used for this is HIPS (host-based intrusion prevention system), a method for protecting endpoint devices. We’ll discuss it more in the next section. Another strategy you can use is to install something like fail2ban . This prevents brute-force login attacks. The best part is that it also helps monitor other networking protocols (like HTTP, FTP, etc.). Beyond conventional antivirus and rootkit measures, behavioral analysis is a strategy that detects abnormal activities that could indicate an attempt at a breach. This involves employing advanced security systems with machine learning algorithms to understand standard server operation patterns so deviations can be flagged as potential security incidents. Administrators can monitor unusual system calls, log changes, or network traffic spikes to detect threats that traditional antivirus tools might miss. Secure configurations and regular system updates are essential things you must insist on. The system regularly fixes all the bugs and problems, but it may become outdated. Even worse, when the patch notes come out, you’re virtually broadcasting to the world all the flaws, putting all legacy systems in even greater jeopardy. These updates need to be systemic and scheduled to be reliable. Implementing Host Intrusion Prevention Systems (HIPS) Previously, we’ve mentioned HIPS; however, it’s such a monumentally important cybersecurity feature that it deserves a section of its own. This system employs several methods, from resetting the connection and blocking traffic to logging the malicious activity for future investigation. HIPS is incredibly accurate at detecting anomalies and deviations in bandwidth, protocols, and ports. Every time an activity varies outside an acceptable range, the system will be alerted. What’s unique about HIPS, however, is that it won’t respond immediately. An anomaly is not always an attack, as not every lump is a tumor. HIPS aims to protect the server without disrupting its regular working order. Reinforcing Linux Server Security through Best Practices You must find the right way to harden your Linux server to the best of your abilities. First, you want to enable strong authentication and create an SSH key pair. This way, you will create a more secure means of accessing your servers. This will make all brute-force attacks nearly impossible, as itoffers much more complex protection than a regular password. Think of it as a cybersecurity equivalent of in-depth defense, a martial concept where you have defensive lines one behind another. By removing unnecessary software, you limit third-party software’s access to your servers. In a way, this enables you to plug all the cybersecurity leaks. Anticipating Future Threats: The Importance of Proactive Security Measures The biggest challenge in cybersecurity is that the landscape is constantly shifting. There are always new threats, challenges, exploits, and problems for you to discover. To address this, you must conduct frequent and significantly more effective audits. Injection flaws, broken authentication, data exposure, and XSS can all be solved effectively if you notice them in time and have the right tools to solve them. Tools like Burpsuite and SQLmap can quickly fix the problem. However, to solve a problem, you must first know you have one. In other words, you need a schedule, a system, and the right toolset. Without all three, you won’t be as quick to adjust to changes. Our Final Thoughts on Improving Linux Server Security A considerable portion of the internet runs on Linux servers, so you must put in extra effort to keep them secure. The art of improving the cybersecurity of Linux servers has massive ramifications for the entirety of the digital world. To enhance server security, you must understand their threats, use the right tools, and ensure you’ve hardened the system enough to become as resilient as possible. Moreover, you must always anticipate and be ready for future threats. . Shield your Linux servers from malware and potential risks by implementing robust security measures and utilizing effective tools.. Linux Server Security, Malware Protection, Antivirus Strategies, Rootkit Detection. . Brittany Day
Linux is an open-source operating system that has been popular among developers and IT professionals for its stability and security . However, over the years, Linux has faced its fair share of security threats in the form of malware. In this article, we will discuss the history of malware on Linux and what measures are being taken to stop it. . The first known instance of malware on Linux was in 1999, when a worm named “Ramen” spread rapidly through the Internet. Ramen exploited vulnerabilities in Linux systems, causing significant damage to infected machines. This was a wake-up call for the Linux community, which had previously considered the platform to be immune to malware. In the years that followed, Linux faced numerous malware attacks, including viruses, Trojans, and spyware. The most notable of these was the “Slammer” worm, which caused widespread damage to the Internet in 2003. Slammer targeted a vulnerability in Microsoft SQL Server and was able to infect Linux systems that were running the software. Despite the increasing threat of malware, the Linux community continued to develop and improve the security of the platform. In 2005, the Linux Kernel Security Project was launched to focus on the development of secure kernel-level code. This was followed by the launch of the Linux Malware Detect project, which aimed to provide a fast and efficient way to detect malware on Linux systems. In recent years, the threat of malware on Linux has become more sophisticated, with attackers leveraging advanced techniques such as fileless malware and weaponized documents to compromise systems. To counteract these threats, the Linux community has continued to develop new security technologies and techniques. For example, the introduction of containers and virtualization technologies has helped to isolate systems and reduce the attack surface of Linux systems. Top Six Malware Threats Affecting Linux Servers Linux servers, although less vulnerable than Windows servers, are not immune to malwarethreats. In this article, we will discuss the top six malware threats that affect Linux servers. SSH Brute Force Attacks These attacks target the Secure Shell (SSH) protocol, a protocol used for remote login to a server. The attacker repeatedly tries to guess the login credentials through automated processes until they succeed. To protect against these attacks, it is recommended to implement strong passwords, limit login attempts, and use key-based authentication. Rootkit A rootkit is a type of malware that gives attackers unauthorized access to a server by hiding their presence and activity. This makes it difficult to detect and remove rootkits, as they often modify system files and alter the behavior of security tools. Regular system scans and updates, as well as using a host-based intrusion detection system, can help mitigate the risk of a rootkit attack. Cryptojacking Cryptojacking is a type of attack where the attacker hijacks the server's resources to mine cryptocurrency. This type of attack can slow down the server and consume large amounts of resources, potentially causing performance issues. Implementing software that blocks known malicious domains and IP addresses, as well as regularly updating the system, can help prevent cryptojacking attacks. Backdoors Backdoors are a type of malware that allows an attacker to bypass normal authentication procedures and gain unauthorized access to a server. Backdoors can be installed through various means, including exploiting vulnerabilities, phishing attacks, or through malicious software downloads. Regular system scans and updates, as well as monitoring network traffic, can help detect and prevent backdoor attacks. Botnets Botnets are a network of infected computers that can be controlled remotely by an attacker. They are often used to launch distributed denial-of-service (DDoS) attacks or send spam. Botnets can infect Linux servers through vulnerabilities, phishing attacks, or through malicious software downloads. Regular system updates andscans, as well as monitoring network traffic, can help prevent botnet attacks. Web Shells A web shell is a type of malware that allows an attacker to remotely execute commands on a server through a web interface. They are often used to carry out malicious activities, such as data theft or DDoS attacks. Web shells can be installed through various means, including exploiting vulnerabilities, phishing attacks, or through malicious software downloads. Regular system scans and updates, as well as monitoring network traffic, can help detect and prevent web shell attacks. Linux servers are not immune to malware threats, and it is important to take steps to protect against these attacks. Implementing strong passwords, limiting login attempts, using key-based authentication, regularly updating the system, and monitoring network traffic are some of the ways to protect against these threats. It is important to be vigilant and stay informed of the latest threats, as the cybersecurity landscape is constantly evolving. Open Source Proactive Approach to Security The Linux community has also adopted a proactive approach to security , with the development of secure coding practices and regular security audits of the Linux codebase. In addition, the Linux Foundation hosts a range of security projects and initiatives aimed at improving the security of Linux systems. To further enhance the security of Linux systems, the community has developed a range of security tools and utilities. These include firewalls, intrusion detection systems, and antivirus software. These tools are designed to detect and prevent malware infections, and to help administrators respond quickly to security incidents. One of the key strategies for stopping malware on Linux is to educate users about the importance of security. The Linux community has been working hard to raise awareness of the threat of malware and to provide users with the information and tools they need to keep their systems secure. This has included the development ofonline resources, such as security blogs and forums, and the creation of security training programs for users and administrators. Is Linux More Susceptible to Malware Attacks Than Other Operating Systems? Linux has historically been considered more secure than other operating systems , such as Windows, due to its open-source architecture, which allows for a more transparent development process and easier identification of vulnerabilities. Additionally, the Linux community has a strong focus on security and promptly addresses vulnerabilities when they are discovered. However, the popularity of Linux-based systems, such as Android, has increased the attack surface and made Linux a more attractive target for malware authors. Additionally, as with any operating system, Linux is only as secure as the practices and configuration of the individual users and organizations running it. Overall, while Linux is less susceptible to malware attacks than other operating systems, it is still important to follow best practices for security and regularly update software to minimize the risk of an attack. What Can Be Done to Stop Malware Attacks on Linux? To stop malware attacks on Linux, the following steps can be taken: Keep software up-to-date : Regularly update the operating system and installed applications to fix vulnerabilities and prevent exploits. You can use tools such as apt-get or dnf on Debian and Red Hat based systems, respectively. Use strong passwords: Implement strong password policies and use unique, complex passwords to prevent brute-force attacks. You can use tools such as pam_cracklib to enforce strong password policies. Use anti-malware software: Install and run anti-malware software that can detect and remove malware. Examples of anti-malware software for Linux include ClamAV, Sophos Antivirus, and Malwarebytes. Enable firewalls: Enable the built-in firewall or install a third-party firewall to block unauthorized network access and prevent malwarefrom spreading. Examples of firewalls for Linux include ufw, iptables, and firewalld. Practice safe browsing: Be cautious when downloading and installing software and avoid clicking on suspicious links or attachments. You can use browser extensions , such as uBlock Origin or NoScript, to block unwanted scripts and advertisements that could be malicious. Limit user privileges: Limit the privileges of users and run applications as a non-privileged user whenever possible. You can use tools such as sudo or su to run applications as a non-privileged user. Use a sandbox: Run applications in a sandbox environment to contain any potential malware and prevent it from affecting the rest of the system. You can use tools such as Firejail or AppArmor to create a sandbox environment for applications. Regular backups: Regularly backup important data to prevent data loss in case of an attack. You can use tools such as rsync or duplicity to perform backups. These methods, along with the specific tools and applications mentioned, can help to reduce the risk of malware attacks on Linux systems. However, it's important to stay vigilant and continuously update security measures as new threats emerge. Technologies Currently Under Development to Stop Malware Attacks on Linux There are several technologies currently under development to stop malware attacks on Linux, including: Machine learning Machine learning algorithms are being developed to detect and prevent malware attacks in real-time, by analyzing patterns of behavior and identifying suspicious activity. Applications: ClamAV: An open-source antivirus engine that uses machine learning to detect malware. OSSEC: A host-based intrusion detection system that uses machine learning to detect threats. Containerization Containerization technologies, such as Docker and Kubernetes, are being used to isolate applications and prevent malware from spreading across the system. Applications: Docker: Apopular open-source platform for building, shipping, and running distributed applications in containers. Kubernetes: An open-source platform for automating deployment, scaling, and management of containerized applications. Sandboxing Sandboxing technologies allow applications to run in a confined environment, limiting the ability of malware to access the underlying system and reducing the risk of infection. Applications: Firejail: A lightweight sandboxing tool for Linux that can be used to run applications in a confined environment. AppArmor: A Linux security module that provides fine-grained control over application behavior and can be used to enforce sandboxing. Virtualization Virtualization technologies, such as virtual machines, are being used to create isolated, secure environments for running applications, reducing the risk of malware infections. Applications: KVM: A full virtualization solution for Linux that can be used to create isolated virtual machines. VirtualBox: An open-source virtualization platform that can run multiple operating systems on a single physical machine. Endpoint protection Endpoint protection solutions are being developed to provide comprehensive security for devices running Linux, including anti-malware, firewall, and intrusion detection and prevention. Applications: ClamAV: An open-source antivirus engine that provides endpoint protection for Linux devices. AIDE: A file and directory integrity checker that can detect changes to the file system and alert administrators to potential malware infections. File-integrity monitoring File-integrity monitoring tools are being developed to detect changes to the file system, alerting administrators to potential malware infections and helping to prevent data loss. Applications: Tripwire: An open-source file-integrity monitoring tool that can detect changes to the file system and alert administrators to potential malware infections. OSSEC: A host-basedintrusion detection system that provides file-integrity monitoring and can detect changes to the file system. Patch management Automated patch management solutions are being developed to make it easier to keep systems up-to-date and secure against known vulnerabilities. Applications including yum, dnf and apt-get provide a convenient and automated way to manage software updates and security patches on Linux systems, reducing the time and effort required to keep systems secure and up-to-date. They help to stop malware attacks by ensuring that known vulnerabilities are patched, making it more difficult for attackers to exploit those vulnerabilities and gain access to systems. These technologies are aimed at improving the security of Linux systems and reducing the risk of malware attacks, while also making it easier to manage security and ensure that systems remain protected over time. Our Thoughts In conclusion, the history of malware on Linux has been a story of evolution, as the Linux community has adapted to changing security threats and improved the security of the platform. Today, Linux is considered to be one of the most secure operating systems available, and the Linux community continues to work hard to keep it that way. Whether it’s through the development of new security technologies, the adoption of secure coding practices, or the education of users, the Linux community is committed to protecting Linux systems from the threat of malware. . Explore the evolution of Linux-related malware, its ramifications, and the continuous initiatives by the community to address and mitigate security vulnerabilities effectively.. Linux Malware, Malware Detection, Open Source Security, Cyber Threats, System Security. . Dave Wreski
Honeynets are an invaluable offensive security tool for learning the tactics and motives of the blackhat community and sharing the information and insights gathered. This article will explore what a Honeynet is, its value, how it works and the risks involved with deploying a Honeynet. It will also examine some great open-source honeynet options your organization may wish to consider. . What is a Honeynet? A Honeynet is a type of honeypot - or resource whose value is being probed, attacked, or compromised - that is designed specifically for research. The traditional value of honeypots has been their ability to deceive blackhats and detect attacks. Smokescreen Product Manager Amir Moin elaborates on the value of honeypots: “Organizations can reap a myriad of benefits from deploying honeypots as part of a comprehensive threat detection strategy. Quality deception technology can help identify targeted threats with a very low rate of false positives. This technology is highly effective in detecting credential phishing attacks, identifying privilege escalation and lateral movement, protecting remotely accessible services and improving active directory security.” A Honeynet is different from a traditional honeypot - it can be categorized as a research honeypot. This does not make it a better solution than a traditional honeypot; merely it has a different purpose. Instead of a honeynet’s value lying in the ability to detect or deceive attackers, its value lies in the ability to gain information on threats. The two biggest design differences between classic honeypots and honeynets are: A honeynet is not a single system, but rather a network of multiple systems. This network sits behind an access control device where all inbound and outbound data is controlled and captured. This captured information is then analyzed to gain insight into the tools, tactics, and motives of the blackhat community. Honeynets can utilize multiple systems at the same time, such as Solaris, Linux, WindowsNT, Cisco router, Alteon switch, etc. This creates a network environment that more realistically mirrors a production network. Also, by having different systems with different applications, such as a Linux DNS server or a web server administrators can learn about different tools and tactics. Perhaps certain blackhats target specific systems, applications or vulnerabilities. Having a variety of operating systems and applications enables researchers to accurately profile specific blackhat trends and signatures. All systems placed within the Honeynet are standard production systems. These are real systems and applications - the same ones that are found on the Internet. Nothing is emulated nor is anything done to make the systems less secure. The risks and vulnerabilities discovered within a Honeynet are the same as those that exist in many organizations today. One can simply take a system from a production environment and place it within the Honeynet. It is these two design differences that make a Honeynet primarily a research tool. It can be used as a traditional honeypot, for purposes such as detecting unauthorized activity; however, a Honeynet requires significantly more work, risk and administration. It is simply not worth the effort of building and maintaining a Honeynet merely to detect attacks. For the sole purpose of detecting attacks, administrators are far better off with the simpler honeypot solution mentioned above. The Value of a Honeynet Traditionally, information security has been purely defensive. Firewalls, Intrusion Detection Systems, encryption; all of these mechanisms are used defensively to protect one's resources. The strategy is to defend one's organization as best as possible, detect any failures in the defense, and then react to those failures. The problem with this purely defensive approach is that the enemy is offensive and on the attack. Honeynets attempt to change this approach to security by giving organizations the ability to be proactive and take theinitiative. The primary purpose of a Honeynet is to gather information about threats that exist. New tools can be discovered, worms can be captured and analyzed before they do extensive damage and attack patterns can be determined. Captured information can also be used as an early warning system, alerting users of attacks before they happen. Honeynets can also provide an organization with valuable information on its own security risks and vulnerabilities. Honeynets can consist of the same systems and applications that an organization is using for its production environment. Risks and vulnerabilities that exist in a Honeynet (which is far more closely monitored and analyzed) identify risks and vulnerabilities in an organization's production environment. For example, a company may want to implement a new web server interface for credit card use. Both the system and application can first be tested in a Honeynet environment to identify any unknown risks or vulnerabilities. Additionally, a Honeynet can help an organization develop its Incident Response capabilities. It can vastly improve an organization’s ability to detect, react to, recover from and analyze systems that have been compromised. The advantage of analyzing these compromised systems is that, since most of the answers already exist, these systems can be viewed as a 'challenge', allowing organizations to test their abilities to determine what happened using various forensic techniques. These results can be compared to the data captured from within the Honeynet. This information can also be used to determine if any other systems within an organization’s production network have been compromised. How Honeynets Work Conceptually, Honeynets are a simple mechanism. In many ways, a honeynet is similar to a fishbowl - researchers and security professionals can see everything that happens inside it and watch for and monitor attackers in the network. Also, just like a fishbowl, there are many options for adding to and altering a Honeynet. Traditionally, the greatest problem security professionals face in detecting and capturing blackhat activity is information overload. The challenge for most organizations is determining from vast amounts of information what is production traffic and what is malicious activity. Tools and techniques such as Intrusion Detection Systems, host based forensics, or system log analysis attempt to solve this problem by using a database of known signatures or algorithms to determine what is production traffic and what is malicious activity. However, information overload, data pollution, unknown activity, false positives and false negatives can make analyzing and evaluating activity extremely difficult. Like all honeypots, the Honeynet solves this problem of data overload through simplicity. A Honeynet is a network designed to be compromised, not to be used for production traffic. Thus, any traffic entering or leaving the network is suspicious by definition. Any connection initiated from outside the Honeynet into the network is most likely some type of probe, attack or other type of malicious activity. Any connection initiated from the Honeynet to an outside network indicates that a system was compromised - an attacker has initiated a connection from his newly hacked computer and is now going out to the Internet. This concept greatly simplifies data capture and analysis. There are two critical requirements that define every Honeynet: Data Control and Data Capture. If there is a failure in either requirement, then there is a failure within the Honeynet. Honeynets are extremely flexible tools; they can be built and deployed in a variety of different ways. As a result, almost no two Honeynets look the same; however, they must all meet the requirements of Data Control and Data Capture. Data Control is what mitigates risk. It controls the attacker's activity by limiting what can happen both inbound and outbound. The risk is that once an attacker compromises a system within the Honeynet, they can then use thatsystem to attack other non-Honeynet systems, such as organizations on the Internet. The attacker must be controlled so they cannot compromise non-Honeynet systems. Data Capture collects all the activity that happens inbound, outbound, or within the Honeynet. It provides valuable insight by capturing attackers’ activities. The trick is to both control and capture attackers’ activity, without them realizing that they are within a Honeynet. There is a third requirement, Data Collection; however, this is only for organizations that have multiple Honeynets in distributed environments. Many organizations will have only one Honeynet, so all they need to do is control and capture data. However, organizations that have multiple Honeynets logically or physically distributed around the world have to collect all of the captured data and store it in a central location. By doing this, the captured data can be combined, exponentially increasing its value. The Data Collection requirement provides the secure means of centrally collecting all of the captured information from distributed Honeynets. Data Control As stated above, data control is the containment of activity. When dealing with blackhats, there is always risk that must be mitigated. It is critical to ensure that once compromised, a honeypot cannot be used to harm any system outside the Honeynet (anything inside the Honeynet is fair game). However, the challenge is to control the data flow without making blackhats suspicious. Once a system is compromised, blackhats will often require Internet connectivity, such as retrieving toolkits, setting up IRC connections, etc. We have to give them the flexibility to execute these actions, as these are the very steps we want to learn and analyze. Also, blackhats may become highly suspicious if they cannot initiate any outbound connections. We made that very same mistake with our first honeypot. We did not allow any outbound Internet connections. It took the blackhat only fifteen minutes to figure outsomething was wrong, wipe the system drive, and leave the network. So, the trick is to give the blackhat flexibility to execute whatever they need, but without allowing them to use the compromised system to attack others with Denial of Service attacks, system scans and other types of exploits. Data Capture Data Capture encompasses the capturing of all malicious activities that occur within a honeynet. It is these activities that are then analyzed to learn about the blackhat community. The challenge is to capture as much data as possible, without blackhats figuring out what is going on. This is done with as few modifications as possible, if any, to a honeypot. Also, data captured must be stored remotely - it cannot be stored locally on the honeypot. Information stored locally could potentially be detected by the blackhat, alerting them that the system is a Honeynet. Data stored locally is at risk of being lost or destroyed. Successful Data Capture is done in layers - no single layer will capture adequate information. Rather - data must be gathered from a variety of resources. Only a multi-layered approach reveals “the big picture”. The first layer of logging activity is the firewall. The firewall logs all connections initiated to and from the Honeynet. This information is critical, as all connections are suspicious. Firewalls should be designed not only to log all connections, but to also alert the administrator whenever a connection is attempted. This is extremely useful for tracking scanning patterns. Additionally, a firewall can detect backdoors or proprietary ports. Most exploits create a shell or backdoor on a system. These backdoors are easy to detect when the firewall alerts of a connection on a system on a random high port. The firewall should also send an alert when a honeypot on the Honeynet initiates an outbound connection. The firewall once again logs this activity - indicating that a system was compromised. Another critical layer is the IDS system, which has twopurposes. The first, and by far most important, is to capture all network activity. The primary job of the IDS is to capture and record every packet that hits the wire. The IDS system resides on a 'port monitoring' port, so it can record all network activity. These records are then used to analyze blackhats’ activities. The second function of the IDS system is to alert an administrator of any suspicious activity within the honeynet. Most IDS systems have a database of signatures. When a packet on the network matches a signature, an alert is generated. This function is not as critical for a Honeynet, as any activity is considered suspicious by nature. However, IDS systems can provide detailed information about a specific connection. Data Collection Data Control and Data Capture are two requirements for Honeynet technologies. Any time an organization deploys a Honeynet, it is critical to ensure that these standards are met. Data Collection is different in that it is optional. Data Collection is the aggregation of data from multiple Honeynets to a centralized point. Its purpose is to exponentially increase the value of information collected. Most organizations deploy only a single Honeynet, so Data Collection does not apply. However, some organizations deploy multiple Honeynets. In these cases, there needs to be a standard for Data Collection. When part of a distributed environment, each Honeynet is assigned a unique identifier. Data sent by each Honeynet to a central location is tagged with the unique identifier. This data is then forwarded by each Honeynet to the single data collection point. Virtual Honeynets Virtual Honeynets take the same concepts used in classic Honeynets and implement these concepts into a single system. This implementation has both advantages and disadvantages over clasic Honeynets. The advantages associated with deploying virtual Honeynets are reduced cost and easier management, as everything is combined on a single system. However, this simplicity comes at acost. Virtual Honeynets limit the types of operating systems you can deploy by the hardware and virtualization software they require. In addition, virtual Honeynets carry increased risk - as an attacker could potentially break out of the virtualization software and take over the Honeynet system, bypassing Data Control and Data Capture mechanisms. Open-Source Honeynets: Detect Threats For Free Cyberattacks are rapidly evolving, posing a bigger threat to organizations’ security than ever before. Deception technology is invaluable in detecting advanced attacks and reflecting the costs of these exploits back onto the attackers. Are you looking for a way to recognize the benefits of deception technology for free? Deploying open-source honeynets makes this possible. Smokescreen Product Manager Amir Moin explains, “Deception technology is an effective approach to threat detection. However, some organizations might be apprehensive about investing time and money into this technology without being certain that it will work for them. Security teams at these organizations can use open-source honeynets to “test the waters” and demonstrate value to management without spending a dime.” Here are some great open-source honeynet options you may want to consider: All-in-One Modern Honey Network (MHN) is a centralized server for honeypot management and data collection. It combines Snort, Kippo, Dionaea and Conpot. MHN is user-friendly and easy to install. Honeydrive is a GNU/Linux distribution that comes pre-installed and offers a host of active defense capabilities. It can be viewed as the “anti-Kali”. Network Services Honeynets Cowrie is a medium to high interaction SSH honeypot which emulates an interactive SSH server with customizable responses to commands. It is designed to log brute force attacks and the shell interaction performed by attackers. Dionaea is a multi-protocol honeypot that covers everything from FTP to SIP. It excels in SMB decoys, and isable to simulate malware payload execution to analyze multi-part stagers. Honeyclients and Malware Analysis Cuckoo Sandbox is not technically a honeypot; however, it’s an excellent sandbox for malware analysis. This tool allows you to safely execute possible malware samples, and it provides a comprehensive report on the code executed. Thug is a low-interaction “honeyclient” that mimics the behavior of a web browser to analyze client-side exploits. Database and NoSQL Honeynets MongoDB-HoneyProxy is a honeypot proxy that emulates an insecure MongoDB database, logging all traffic to a dummy MongoDB server. ElasticHoney emulates an elastic search instance, searching for attempted remote code execution (RCE). Honeytokens Canarytokens by Thinkst Applied Research let you position decoy data across your systems for attackers to trigger, helping track activity on your network. Internet of Things (IoT) Honeynets Honeything is a honeypot for Internet of TR-069 Things. It is designed to act as a modem/router with RomPager embedded web server. It supports the TR-069 (CWMP) protocol. SCADA/ICS Honeynets ConPot emulates a wide range of operational technology control system infrastructures, and is designed to be easy to deploy, modify and extend. It provides common industrial control protocols , which can be used to build a system that mimics complex infrastructures to convince a malicious hacker that he or she just found a huge industrial complex. This honeynet also comes with a web server that can emulate a SCADA HMI. GasPot emulates a Veeder Root Guardian AST that is commonly used in the oil and gas industry for monitoring. Honeynet Care, Feeding and Risk Honeynets are not a "fire and forget" solution- they are a complex type of honeypot that requires constant maintenance, administration and vigilance. For maximum effectiveness, administrators need to detect and react to incidents as soon as possible. By watchingblackhat activities in real-time, one can maximize Data Capture and analysis capabilities. Also, to detect the unknown, suspicious activity must constantly be reviewed. This requires extensive time and analysis capabilities. For example, in just 30 minutes a blackhat can do enough damage to a compromised honeypot to require 30-40 hours in order to fully understand what happened. Constant maintenance is also required to ensure operability of a Honeynet. If something goes wrong - which is definitely not uncommon - the Honeynet Your alert processes may fail, disks can fill, IDS signatures can become outdated, configuration files can become corrupted, system logs will need to be reviewed and firewalls will need to be updated and patched. This represents just a small portion of the constant care and feeding that is required for a Honeynet to be successful. Your work has only begun when you implement a Honeynet! Virtual Honeynets eliminate some of the headaches associated with deploying and maintaining a Honeynet by combining all the elements of a Honeynet onto one physical system. Not only are all three requirements of Data Control, Data Capture, and Data Collection met, but the actual honeypots themselves run on the single system. The honeypots are actual operating systems. Nothing is emulated. The advantage here is one of both cost and efficiency. It is much cheaper to use a single system to run all the elements of a Honeynet, and it is much easier to deploy and maintain. Also, there are risks involved with building and implementing a Honeynet that must be considered. Before deploying a Honeynet, it is important to understand and acknowledge that blackhats will be attacking and compromising these systems. By setting up a network to be compromised, administrators expose both themselves and others to risk. They assume a responsibility to ensure that the Honeynet, once compromised, cannot be used to attack or harm other systems. However, with an Honeynet environment, there is always the potential forsomething to go wrong. There are a variety of measures that can be implemented to mitigate this risk; however, it is quite possible for a blackhat to develop a method or tool that allows them to bypass these access control methods. Also, one needs to be constantly testing and updating the environment to ensure control measures are working effectively. Never underestimate the creative power of the blackhat community! The use of a firewall, routers and other techniques can help mitigate the risk of a Honeynet being used to damage other systems. However, there is risk associated with any Honeynet regardless. Finally, Honeynets should not be viewed as a solution for all of an organization’s security problems. LinuxSecurity Founder Dave Wreski cautions: “Organizations should focus on best practices first, such as strong authentication, use of encrypted protocols, reviewing system logs and secure system builds. By prioritizing proper policies and procedures, risk can be greatly reduced. Honeynets do not reduce risk - they most likely increase it. Honeynets are designed to gather information on the enemy - they will not fix unsecured servers, nor will they fix bad processes or procedures.” Conclusion Honeynets are a type of honeypot designed to gather information - specifically the tools, tactics and motives of the blackhat community. This information can be used to protect organizations against various threats. There are two design differences between traditional honeypots and a Honeynet. The first difference is that a Honeynet is not a single system, but a network of multiple systems and applications. The second difference is that Honeynets are production systems - the same systems found on the Internet. Neither the systems nor the vulnerabilities are emulated. This combination makes Honeynets an excellent research tool. However, Honeynets require a tremendous amount of administrative overhead. The Honeynet administrator has the responsibility of ensuring that no other systems will beattacked from a compromised Honeynet. LinuxSecurity Founder Dave Wreski evaluates the risks and benefits associated with deploying Honeynets: “Without proper administration, the risks of using a Honeynet may outweigh the reward. This tool is not a cure-all or a “band-aid” for fundamental security flaws, and it may not be a suitable solution for every organization. Organizations should first focus on securing their systems. Once secured, they may then be able to utilize Honeynets as a powerful tool to take the initiative and learn more about both the enemy and themselves.” . What is a Honeynet? A Honeynet is a type of honeypot - or resource whose value is being probed, atta. honeynets, invaluable, offensive, security, learning, tactics, motives. . Brittany Day
The Internet has made the world smaller. In our routine usage we tend to overlook that "www" really does mean "world wide web" making virtually instant global communication possible. It has altered the rules of marketing and retailing. An imaginative website can give the small company as much impact and exposure as its much larger competitors. In the electronics, books, travel and banking sectors long established retail chains are increasingly under pressure from e-retailers. All this, however, has come at a price – ever more inventive and potentially damaging cyber crime. This paper aims to raise awareness by discussing common vulnerabilities and mistakes in web application development. It also considers mitigating factors, strategies and corrective measures. . The Internet has become part and parcel of the corporate agenda. But does the risk of exposing information assets get sufficient management attention? Extension of corporate portals for Business-to Business (B2B) or developments of websites for Business-to-Customer (B2C) transactions have been largely successful. But the task of risk assessing vulnerabilities and the threats to corporate information assets is still avoided by many organisations. The desire to stay ahead of the competition while minimising cost by leveraging technology means the process is driven by pressure to achieve results. What suffers in the end is the application development cycle; - this is achieved without security in mind. Section 1 of this paper introduces the world of e-business and sets the stage for further discussions. Section 2 looks at common vulnerabilities inherent in web application development. Section 3 considers countermeasures and strategies that will minimise, if not eradicate. some of the vulnerabilities. Sections 4 and 5 draw conclusions and look at current trends and future expectations. The TCP/IP protocol stack, the underlying technology is known for lack of security on many of its layers. Most applications written for use on the Internet usethe application layer, traditionally using HTTP on port 80 on most web servers. The HTTP protocol is stateless and does not provide freshness mechanisms for a session between a client and server; hence, many hackers take advantage of these inherent weaknesses. TCP/IP may be reliable in providing delivery of Internet packets, but it does not provide any guarantee of confidentiality, integrity and little identification. As emphasised in [1], Internet packets may traverse several hosts between source and destination addresses. During its journey it can be intercepted by third parties, who may copy, alter or substitute them before final delivery. Failure to detect and prevent attacks in web applications is potentially catastrophic. Attacks are loosely grouped into two types, passive and active. Passive attackers [6] engage in eavesdropping on, or monitoring of, transmissions. Active attacks involve some modification of the data stream or creation of false data streams [6]. [ Download full feature PDF ] . The Internet has become part and parcel of the corporate agenda. But does the risk of exposing infor. internet, world, smaller, routine, usage, overlook, 'www', really. . Benjamin D. Thomas
Anton Chuvakin discusses the known approaches to choosing the level of security for your organization, risk assessment, and finding the balance between effective security practices and the existing budget. . Scary stories of companies gutted by the worm attacks, virus outbreaks, malicious hacker intrusions and other information risks are plentiful. The rising exploitation of most existing vulnerabilities is combined with the appearance of new ones resulting in a new and powerful threat to Internet users (see, for example, 2001 CSI/FBI Survey, a standard cyber crime statistical reference). The security industry often takes the position that companies should promptly design and implement more and more security, increase its priority within the business and train all computer users in using the multiple layers of enterprise defense. Similar advice is given to small office, home office and individuals using the Internet from home. Firewall or at least a filtering router is now considered a standard network protective measure for any company. Personal firewalls are recommended for all home users on broadband Internet connections. However, companies will often choose to comply only with the reduced set of requirements due to business needs. So far, it sounds like the beginning of a typical security convincer speech. In fact, the rarely addressed issue of choosing an appropriate level of security for the organization is about to be investigated. All organizations are different; they have different needs (that includes security needs), resources (that includes human, financial and technology resources) and, on the human side of the problem, different perceptions of "how much is enough" security. The article addresses common approaches to information technology risk management and discusses some of the issues that can simplify the assessment and mitigation of these risks. It summarizes existing knowledge in the area and gives someuseful hints on IT risks. It should be noted, that by enforcing security we understand maintaining the classic CIA: Confidentiality, Integrity, Availability. Many experts claim that an average company has "too little" security. However, if you ask the CTO you will sometimes hear that they have "just enough". Apparently, their business process was going on just fine with whatever level of security they had. As someone said, selling security to management is sometimes like asking to pay real many for hypothetical (unlike fire, flood, earthquake) risks. Often, company chooses to implement security only after the major incident strikes them or their competitors, just as emergency planning was brought to light after September 11. What are the known approaches for choosing the level of security? Here are a few of the common ones discussed in a security literature. "No security" used to be a viable option for smaller companies, which considered their information assets as being of little interest to attackers. Believing that "we are too small to be attacked" has proved to be an inherently flawed logic. The popularity of random IP address scanning tools employed by "script kiddies"*, mass deployment of DDoS zombies and recent rise of IIS worms makes this option a perilous choice. Whoever owns a computer does have something of interest to malicious hackers - it can be the hard drive space for hosting a "warez" site, processor power for cracking passwords from other systems or network connection for attacking third parties. In addition, while the threat of "due diligence" lawsuits has not materialized yet, it is often quoted as a motivation for implementing basic security measures. "As much as management allows" is usually simply too little - too late. After the next well-publicized bug story or a security incident, the company decides to implement a certain security measure, such as deploying a firewall. It mightor might not be helpful for overall enterprise security, since technology safeguards implemented without the foundation of a solid security policy are rarely helpful. For example, having a firewall but allowing most of the potentially dangerous protocols through due to "company needs" does not lower the risk by any significant amount. "Qualitative risk assessment" , while favored by many in security industry, is a rather controversial method due to the high degree of uncertainty associated with some IT risks. Several techniques were developed for defining the appropriate level of security spending based on risk. One way is to find risk level by multiplying the threat frequency by the loss amount. Then the resulting amount is compared with the value of protected asset. It is sometimes referred to as Annual Loss Expectancy method and goes back to the FIPS publication 65 from 1979. The problem is that often both loss frequency and amount are totally unknown in many cases for digital risks. For some risk factors, there is not enough statistical data accumulated, some are usually not reported to the authorities, while others are too new and unpredictable. At whatever level of digital risk assessment currently is, it will be needed when digital risks insurance finally catches up since that is the way insurance companies seem to operate. "Best practices" is another often mentioned method to manage company information technology risks. It avoids the uncertainty of a formal risk analysis by relying on the commonly accepted baseline for security protection. Projects such as CASPR (Commonly Accepted Security Practices & Recommendations) or GASSP (Generally Accepted System Security Principles) are aimed at developing the common set of guides on all areas of security. For example, CASPR uses the following topics to organize the developed guides: Operating System and System Security, Network and Telecom Security, Access Controland Authentication, Infosecurity Management, Disaster Recovery and Business Continuity, Infosecurity Auditing and Assessment, Logging and Monitoring, Application Security, Application and System Development, Computer Operations, Investigations and Forensics and Cryptography. By summarizing the methods and techniques to handle technology risks from the majority of industry players, the documented best practices can effectively protect the company that adopts them from attacks and liability suits. Implementing this approach requires the minimum amount of analysis and planning. British standard BS 7799 that recently became the international standard ISO 17799 is another example of the best practices guides. A lot of information is available on the web, for a nice overview and a short resource list, visit the ISO17799. It should be noted that using best practices provides better protection from liability lawsuits than from the actual network intrusions. Some other disadvantages of utilizing this approach are the independence from actual risks that can lead to both over-securing and under-securing, lack of information collection on new threats and difficulties in measuring the efficiency of security procedures. "Scenario analysis approaches" involve creation of various scenarios in which computer security can be compromised. After the threat scenario is created the appropriate mitigation procedure should be developed, deployed and tested. Scenarios can also be used to demonstrate how vulnerable the company is to certain threat factors: for example, penetration testing can show that the company is exposed to insider risks and that the methodology to handle them should be built. This approach requires brainstorming of as many risks as possible done by internal security staff and outside security consultants. Unfortunately, all hazards can never be brought to light. It limits the effectiveness of the scenario-based approach.In case an important and high-probability threat factor is missed in the methodology, the financial loss can be severe. In brief, under this approach the security program will address only those risks for which loss scenarios are developed. Cost-benefits analysis is an attempt to base the choice of security safeguards on the asset cost alone. Apparently, deploying a $10,000 to protect $1,000 information on a server is not a wise decision no matter what the risk is. Cost-benefit analysis allows drawing a line limiting the price of projected security technologies. The cost of protected assets can be used to determine the security requirements, which are than compared with organization technological and human resources. This does not involve any risk assessment, thus the question whether the asset is actually at risk is never asked. However, this method certainly provides a useful way to start the security infrastructure design. Insuring all risks might become a promising option for companies that cannot afford designing a full-blown security architecture in the near future. It might not be the most effective option since it just transfers the need to do assessment to the insurance company. Likely, some combination of managed risk and insured risk will eventually become a standard. Overall, the knowledge of the above methods can help you increase the safety of doing business. Risk assessment is not an esoteric process. Let us apply all of the above methods to a simple IT risk. To those in the know, the example might look simplistic, but it does serve as a useful illustration. For example, security administrator of the site is asked to let the instant messenger (such as ICQ, AIM or MSN Messenger) communication though the firewall. The case of no security is trivial - the protocol is allowed and no second thought is given to the issue. Qualitative risk assessment is complicated: there is no statistical dataon IM risks to the company and only the anecdotal evidence is available. Thus, it is impossible to evaluate the probability and the amount of loss, unless one chooses to trust the risk evaluation based on insufficient data. Best practices approach will call for checking the industry guidelines on allowing IM communication through. In this case, most of the guides will advise against doing this, unless a clear business need for IM use is established. Scenario-based approach will look for all ways to abuse IM and will make provisions for responding to each of them. Security team might want to demonstrate how IM is used as an attack vector and then create appropriate safeguards if they are possible. In case ways to cause loss, using IM cannot be handled by security procedures, the software is not allowed. Cost-benefit analysis might determine that the savings from less phone calls that stem from using IM software will be bigger than endangered assets in engineering department, while in case of accounting department the risks might outweigh the benefits. Thus, IM will be allowed in one case and banned in another. In addition, several important points related to risk strategies should be made. Whatever method of handling risks is implemented, security policy should relate the resources with corresponding protection measures. Thus, policy is written after all organization resources are evaluated and risk assessment (if it is required by the chosen risk mitigation model) is completed to establish the guidelines to be followed by the company. Policy should also be reviewed regularly to reflect the changes in the enterprise and security environment. After an appropriate level of security is carefully chosen and fixed by the written policy, the problem of convincing users to use it remains. Another important requirement is to keep current with all the security-related information, since new vulnerabilities are found everyday. Malware attacks happen with no advance warning and can be initiated by strangers or disgruntled employees seeking revenge. Malicious hackers need only know a single vulnerability to get through your defenses. And you have to defend against all of them. It requires following the changes in security technology, IT industry and even hacker underground. Once you know the enemy you must still implement a defense strategy. Security awareness program for employees should be a crucial part in any infosec policy. Unless the employees are trained in using the deployed security technologies, the effectiveness of those controls will fall apart. In addition, people responsible for critical computing resources should complete a more rigorous infosecurity training to understand all of the security implications of their job functions. Enterprise security education should be kept up to date with technology and current best practices. One possible way to assure the adequate level of cybersecurity knowledge is periodic tests and quizzes based on current policies and procedures accepted by the management. Finding the balance between effective security practices and the existing budget for security is important for every environment. The above guidelines should send the reader in the right direction. When security program is designed, the unfortunate consequence of security measures should be considered. Overall, most security measures hinder usability to some extent. This is a fact, and so far, no workarounds have been developed. We divide all "complications" from security into impact on the information systems and impact on employees. Some of the computer-related issues are: Antivirus software might degrade performance of a desktop system, especially for older computers *Content filtering may remove non-malicious attachment *Firewall may slow down network communication False positives from the IDS and anti-virussoftware heuristic engines create network overhead and undermine employee confidence and value in such security software. Employee related security challenges include: Complicated password policy with no user education, resulting in employees writing passwords on infamous Post-It notes Need to login to many systems to perform daily job duties results in employees selecting the same password or several easily guessable passwords for multiple systems The previous need combined with short system login timeouts causes productivity loss due to a constant need to login Restrictive physical security may result in employees sharing access cards Video surveillance, with no justification, may lower employee morale and degrade trust within an organization Complex remote access procedures may result in some employees installing "black" modems for home access Encrypted email, such as PGP email is hard to use without some level of understanding of public key cryptography Addressing those issues is essential after the security program is designed. Ideally, security should be user-independent (security of the system should not depend upon the decision of an end-user), user-transparent (does not prevent or hinder any authorized action of the user), effective ! (stop all unauthorized actions of a legitimate user and all actions of an intruder) and cost-effective (not cost more than the protected assets). Security measures should also be flexible to reflect a fast-paced and somewhat chaotic environment of the modern infosec threat landscape. To conclude, too much security can be as much of a problem in some cases as too little. Restrictive and unjustified security measures especially those not based on a security policy can lower productivity of human and performance of technology components of a business. Implementing effective security requires careful design, and a need analysis and detailedrisk analysis should be done first. Such assessments are then followed up with an implementation plan, where organizational communication, policy, maintenance plans, training and deployment are considered (to name a few). About the Author Anton Chuvakin, Ph.D. is a Senior Security Analyst with netForensics ( ), security information management company that provides real-time forensics software solutions. His infosecurity expertise includes network security, firewalling, UNIX hardening, security administration, etc.. Evaluate viable security tactics, aligning cost constraints with potential threats to maintain organizational resilience.. IT Risk Management, Security Strategies, Risk Assessment Methods. . Brittany Day
Get the latest Linux and open source security news straight to your inbox.