Log Management & SIEM for Security, Compliance, Operations | the dialog

Lost in the advancements in electronic communications are their legal ramifications. As the United States legal system struggles to keep pace with innovation, courts, companies and individuals must rely upon laws written as far back as the 1930s to regulate the realities of the 21st century. Regulators are in a constant race to keep pace with advances in technology. While new regulations slowly come into being, the United States legal system currently has no choice but to try to mold existing laws into viable solutions for the inevitable problems of ever-evolving electronic communications.

Three agencies share jurisdiction in monitoring the e-communications market: the Department of Justice (DoJ), the Federal Trade Commission (FTC) and the Federal Communications Commission (FCC). Overlap between the FCC and the FTC exists in cases of mergers concerning radio license transfer or common carriers and in cases where there is a violation of both sector specific and antitrust laws.

Several outside recommendations have been put forth to help the FCC more easily regulate electronic communications. This is largely due to failures of the FCC to address key areas of regulation and its decision to remove itself from proactive technical analysis.

Philip Weiser, senior adviser for technology and innovation to the National Economic Council at the White House, recommends a three-part solution. First, the FCC should identify and govern broad areas where cooperation between entities is essential. Second, it should oversee a private sector body that helps the Internet self-regulate. Third, in the event of a breakdown of cooperation between parties, the FCC should act as an adjudicator, rather than a rule maker. Kevin Werbach of The Wharton School feels the FCC should leverage existing, privately created standards. He likens his recommendation to those followed in areas such as accounting and workplace safety, where industry has created standards that regulators enforce. A third course proposed by Christopher Yoo, founding director of the Center for Technology, Innovation, and Competition would have the FCC regulate using a case-by-case approach. This approach would circumvent the adoption of categorical rules that cannot cope with minute distinctions between cases. The common thread in all three arguments is that the FCC should be an adjudicator, rather than a rule maker.

The blurring of the lines between information and communication technologies creates its own set of challenges. Antonios Broumas points out that the Telecommunications, Broadcasting and Information Technology industries are rapidly converging. His concern is that policy makers will not strike a balance between fair competition and encouraging innovation. Broumas’ recommendation is to regulate electronic communications through a convergence of economic rules applied to the market and competition law for ad hoc regulation of individual matters. His desire for ad hoc regulation is similar to the approaches of Weiser, Werbach and Yoo.

In an effort to aid Cyber Security researchers, the Department of Homeland Security (DHS) Science & Technology Directorate’s Cyber Security R&D division put forth the PREDICT1 project. The project is designed to facilitate cyber defense research by providing data to the researchers. PREDICT1 includes an analysis of legal and policy issues associated with each of its data sets. This provides researchers with certainty that the datasets they are using for research are free of legal issues.

No matter what regulations are put forth, enforcing them is very challenging. Simply determining who is processing data is often difficult. If the processing is taking place in a state or country other than where the user resides, who has jurisdiction? Is it the user’s state, or the state or country where the data is stored and/or processed? What happens if the state that is determined to have jurisdiction has few or no information security laws? More than 45 states currently do have Breach Notification Laws that protect users who store personal information online. In short, these laws require that data owners storing a user’s personal information inform the user if unauthorized access of that data has occurred. Despite the existence of these Breach laws, as of 2011 only nine states had laws requiring companies to implement reasonable information security measures. Instead, it is up to the companies themselves to determine what, if any security measures they wish to put in place. Recent case law does show that jurisdiction is most often designated to whoever first dealt with the matter, but this still does not answer the greater question of inconsistent laws from state to state.

Underlying all of these issues is the communications technology itself. TCP/IP cannot guarantee the QoS that streaming applications such as videos, games and telemedicine need. This has led to providers experimenting with prioritizing traffic, which intern sparks many Net Neutrality debates. Net Neutrality brings its own set of challenges to the table that the above recommendations can only hope to assist.

As someone who spent four and a half years in the legal realm, I am fascinated with the challenges of regulation keeping pace with technology. Advancements in technology are rapid. Regulation is not. The Stored Communications Act is 25 years old. The Communications Act of 1934 is 77. Both these laws were written with their respective eras in mind, yet must be applied to the challenges of today until they are amended or replaced. The consensus of the authors above is that the FCC takes the role of an adjudicating organization, rather than a rule making one. Their points are valid. Given technology’s rapid change and the slow speed of lawmakers, it is foreseeable that a new regulation could be obsolete before its ink is dry. For the regulators to be effective, they must create ways to keep pace with the industry they oversee.

Recent highly publicized breaches involving sophisticated attacks and high-profile targets has elevated awareness of Advanced Persistent Threats (APTs) to unprecedented levels. This has left many organizations struggling to understand the risk APTs present to them and how best to protect themselves.

For organizations concerned with APTs, and advanced threats in general, SIEM is a critical component of a defense-in-depth architecture. SIEM’s ability to provide centralized management and analysis of enterprise log data provides unique intrusion detection capabilities and the visibility required to defend against and respond to an APT.

LogRhythm has developed a comprehensive methodology for implementing our SIEM 2.0 solution for detecting and responding to APTs. Our belief is that this methodology provides a blueprint for helping organizations defend themselves against an increasingly hostile and capable threat landscape.

The Challenge of APTs
APTs are threats advanced in method, capability, and resources.This doesn’t always mean they possess advanced technical skills; instead they may have the resources to acquire them. What they do have is an advanced method and approach to achieving their objective. APTs are persistent. They have a specific objective in mind and they will spend months, even years to achieve that objective.

What makes APTs unique and so concerning are their advanced nature and their persistence. They are not an opportunistic criminal trying to find the first unlocked door. They have singled you out for some reason and are ready to spend significant time and resources getting what they want from you.

To compound things, a mature cybercrime economy and supply chain has emerged. APTs and cyber criminals have easy access to for-sale malware, exploits, and forhire capabilities.
This serves as a force multiplier and expediter when combined with the capabilities an APT already possesses.

The greatest challenge in protecting your organization from APTs is the variety of techniques and capabilities they leverage in a persistent nature. An APT might develop or purchase custom malware designed to take advantage of zero-day exploits that will evade traditional defenses. They might combine this with physical theft and clever social engineering. In the end, they will harness the full spectrum of logical, physical and social attack vectors.

APTs and threats like them will continue to increase in number and capability as cyber crime and the supporting economy keeps maturing. We can also expect nation states and cyber-terrorists to continue investing in and honing their cyber warfare arsenals.

APT detection and defense requires a comprehensive approach. It is more than a single technology or process. However, when implemented correctly with good supporting processes, there is no better investment in this defense than SIEM 2.0.

If you find yourself needing to have the contents of an ASCII text file written to syslog, then consider the use of the logger command. This comes with most Unix distributions and has also been ported to the Windows platform.

There may be times whereby an application or system only logs to a text file and this data needs to be collected into your log management solution. For this example, I’ll assume an ASCII text file with single line entries is the log file and its name is logdata.log. In this scenario, you can utilize the logger command utility to read each line of the file and send it to the local Syslog daemon.

The logger command has some useful command line parameters that can be useful to gain additional control over how the log messages are written to syslog. There are subtle differences between the Unix-based and Windows logger command as seen in the syntax below:

Unix-based logger:

logger [-isd] [-f file] [-p pri] [-t tag] [-u socket] [message …]

Windows-based logger:

logger [-?] [-is] [-f file] [-p pri] [-t tag] [-a port] [-l loghost] [-m udp|tcp|3195raw] [message ..]

An example in Unix is shown below:

logger –f logdata.log –p local4.alert Transaction rejected due to invalid data type.
Where the following is true:
logdata.log is the file containing the log messages to be written to syslog.
local4.alert is the facility and severity the log message will have when written to syslog.
“Transaction rejected due to invalid data type.” is the message that is written to syslog.

An example in Windows is shown below:

logger –f logdata.log –p local4.alert –a 514 –l lrx3.host.com –m tcp Transaction rejected due to invalid data type.

Where the following is true:

logdata.log is the file containing the log messages to be written to syslog.
local4.alert is the facility and severity the log message will have when written to syslog.
514 is the port the syslog server is listening on.
lrx3.host.com is the syslog server host that is receiving the log messages from Logger.
tcp is the protocol the syslog server is expecting.
“Transaction rejected due to invalid data type.” is the message that is written to syslog.

Typically, this will be a scheduled job that will execute this vs. manually running this from a command line. If logger exits successfully it will have a return code of “0” – otherwise it will be a value higher than “0”. I used this on a past deployment, where AIX kernel auditing was writing to a file (binary converted to ASCII text) and I needed to collect this data. I utilized logger by scheduling a cron job to pipe the AIX kernel audit log file to the logger command, which in turn wrote this to the local syslog daemon. Because I didn’t specify a file logger used standard input, which in this case was the output of the binary to ASCII conversion process.

If you find yourself in any similar situations, consider the use of logger.