- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Server Security: The Threat from Within
Although the Department of Homeland Security and the televised news media would have you believe that hordes of foreign attackers and terrorists constantly prepare themselves for cyberwarfare, the reality is your greatest threat is currently occupying a cubicle inside your company. The majority of all computer security breaches are those launched by insiders taking advantage of their unrestrained access within the corporate network.You've built a virtual fortress to keep strangers off of your servers and out of your data center, but did you know your greatest enemy is more likely to be one of your own employees?
You might think these statements breed a certain amount of corporate paranoia, and they do. If you weren't paranoid, you wouldn't have network firewalls, antivirus and anti-spyware software, personal firewalls, or 12-character passwords on your accounts.
Potential Internal Security Risks
- Contractors and consultants
- Former employees
- Temporary employees
Your systems come with built-in paranoia in the form of logging and file permissions. Additionally, you should consider a third-party solution that goes beyond those system-level schemes. For example, user activity management (UAM) is one method that reduces theft and unauthorized dalliances. Sure, accidents occur. People make mistakes by typing in the wrong system name, attempting to hit the wrong database or inadvertently accessing a resource for which they have no access. No one has any interest in wasting resources tracking or pursuing those innocent "door knockers."
What you want to pursue are the clever and malicious types who purposely attempt to hack, crack or steal your information, data or client lists. The truly clever hackmeister will cover his tracks by removing or editing logs. Systems permissions won't slow a well-trained hacker. He'll steal the system root or administrator account and "own" the system in a few minutes. System logging and permissions are necessary, but don't trust them 100 percent of the time.
System and event logs provide detailed descriptions of logins, user privilege elevation (switching to the root or administrative user) and failed authentication attempts. The unfortunate bit about logs is that they are an after-the-fact mechanism that requires someone to search through, assess and take action based on logged entries. This is a time-consuming process, and a smart system hacker will remove or edit logs before disconnecting from the compromised system.
Programs exist to watch the logs for attacks. In most cases, you must supply the exact string you want the program to look for and the action to take on discovery of that string. However, such programs may fall victim to the hacker's exploits to the system as well so that no errors or alerts are possible.
System logs are not a defense because they aren't reliable sources of information. In case of an attack or system compromise, check the logs, but realize that what you're reading might be fiction. Hackers will often kill logging programs to halt recording of vital information and restart them just before departure from your system.
Contemporary operating systems have a paranoid permissions system in place. By default, users can do very little. It is this "principle of least permissions" that protects your operating systems and users from each other and themselves. This new locked-down mentality comes from years of system compromises. It might make legitimate work a bit more difficult, but it's for the protection of the data owner -- you.
System users have full control of their "home" directories and can use most system utilities, but restrictions still greatly outnumber privileges. Simply having a user account on a system makes it vulnerable. Giving someone with malicious intent a user account on a system means you have essentially won half the battle for him. He can now compromise the system by downloading applications that will assist him in his evil task: compromising your system.
Permissions are still your primary defense against local or remote system hackers. You need strictly enforced user and group policies for all multiuser systems.
User Activity Management
The best defense against internal hackers is an active network-based transaction "sniffer" that collects data on all network activities and alerts based on rules that aren't string-oriented. In other words, rules based on activities rather than on specific log strings. This is a UAM system such as the solution provided by PacketMotion.For example, "Do not allow John Smith to delete Word documents from any server" or "Alert if any user attempts to access the 'Salaries' table from the Payroll database." If a user violates one of these rules, a database records the entry, including the user name, the file accessed, the containing folder, the host system, and the operation (read, write and open) along with a time stamp.
- Details of each user transaction including
- File and folder names
- Database names, tables and queries
- Chat and instant messenger names
- Login attempts (failed and successful)
- All transaction data from applications and protocols
- So that transactions performed by known users are identified as such
- So that transactions performed by intruders are identified and recorded
If a user performs a blacklisted operation, the UAM can send an alert, block the activity or both. The significant difference in a UAM and simple logging is that you can catch the user in the act with no risk of magically edited or removed logs. This system can prevent attacks as they happen. Blocking the activity involves resetting the connection at both ends silently and then monitoring that connection for further attempts. The UAM records the attempt and the blocked connection activity.
How valuable is my data? Can I afford to lose it or have it stolen? These are the questions you must ask yourself when you consider a solution to the internal security threat that confronts you. You must also answer the question, "How will I handle the employee (or other internal resource) when this activity occurs?" Walking the plank is not an option for mutiny these days, but termination and prosecution are. You've built your fortress; don't leave your hallways unmonitored. Take a tip from elementary schools that have walls but also require a hall pass.
Ken Hess is a freelance writer who writes on a variety of open source topics including Linux, databases, and virtualization. He is also the coauthor of Practical Virtualization Solutions, which is scheduled for publication in October 2009. You may reach him through his web site at http://www.kenhess.com.