Category: General
Continuous Monitoring: How a SIEM Platform Can Help with this Daunting Requirement
(3rd in a series of 3)
Today’s blog entry is the third and final blog in the series on SIEM features which support continuous monitoring requirements. The past two blog entries covered situational awareness, threats, assessing security controls, and collecting, correlating, and analyzing security information. In today’s entry I will cover security status communication and risk management requirements for continuous monitoring.
The FIFTH requirement is “providing actionable communication of security status across all tiers of the organization.” This requirement has to do with the organizations capability to provide accurate communication on the current security status of the organization at all levels within the organization and provide recommended action when needed. This particular requirement is focused on defining, providing, and communicating security status and metrics. A SIEM should be capable of providing notification of security-related issues to owners of particular systems allowing them to take remediation action as necessary. The more advance SIEMs actually have the capability to provide automated remediation actions when specific issues are identified. The metric portion of the requirement quantifies the current status of information security at all levels of the organization. The SIEM at a minimum should be able to provide an audit trail of the actual uses of the SIEM as part of a metric. The SIEM should audit alerts generated by critical events, the analyst’s acknowledgment of the alert, investigations initiated by the analyst in response to the event, and actions taken to remediate the threat of the event, and review of the event by management.
The SIXTH and final requirement is “active management of risk by organizational officials.” This particular requirement indicates that management must actively manage organizational risks. This is really an extension of the risk assessment process which ensures all risks are identified, mitigated, and acknowledged by management. A SIEM should extend managements view of the organizations risk landscape by providing a view of critical risks such as threats and vulnerabilities, and provide visibility to the effectiveness of mitigating controls such as anti-malware, firewalls, IDS, patch management, vulnerability scanners, etc…
A SIEM can be a powerful tool to meet continuous monitoring requirements through automated means. Keep in mind not all SIEMs are created equally and some provide limited functionality at a premium price. Ensure the organization performs an in-depth review of the regulatory requirements along with functional requirements before a SIEM selection is made. Robust SIEMs often provide mappings of key features directly to regulatory control requirements which they meet or supplement. Advance SIEMs which provide capability such as built-in alerts, threat advisories, and automated remediation functionality can help organizations stay informed and better prepared to quickly remediate security risks.
Continuous Monitoring: How a SIEM Platform Can Help with this Daunting Requirement
Blog 1 of 3
Continuous monitoring is one area where most organizations often experience audit related issues during their regulatory review. The most typical issues are often related to analyzing security related information and assessing security controls. Many of my clients would enable logging on the majority of their systems but would not actually analyze any of their logs due to the large volume. I can certainly empathize with them having been in their shoes myself. However it’s not acceptable to stop monitoring critical system logs because the task seems too daunting, there is a better way. A robust SIEM (Security Information and Event Management) solution can centrally collect millions of logs, correlate information across the organizational infrastructure, and alarm on user-defined critical conditions resulting in a manageable subset of security related events. There are many different players in the SIEM market and a wide range of functionality offered; over the next three days my blog entries will tell you about specific features to look for in a SIEM to help meet continuous monitoring requirements.
FIRST, it is important to understand the six main continuous monitoring requirements outlined in NIST (National Institute of Standards and technology) 800-137 before seeking a SIEM solution. The first requirement is “maintaining situational awareness of all systems across the organization.” This describes the need for the organization to keep an awareness of all systems in their organization. Organizations should have an asset management program which actively maintains inventories of systems, software, and network diagrams. A SIEM should supplementary support the asset management program by providing details of all known assets (hosts, network devices, physical devices, security devices, etc…) within the organizations infrastructure. It is also best practice to implement technologies such as NAC (Network Access Control Systems) which have the ability to detect unidentified systems and deny them access to the infrastructure. A SIEM should also collect logs from these types of devices and generate alarms when unidentified systems are detected.
The SECOND requirement is “maintaining an understanding of threats and threat activities.” Organization must stay up to date on current threats and have the capacity to identify specific threats to their organization to meet this requirement. They are expected to keep their knowledge of threats current by researching in-scope threats to their systems on a regular basis. There are a variety of content providers which focus on providing threat advisories via RSS feeds. Organizational threats should be identified and assessed through the risk assessment process. However a SIEM should provide continuous threat assessment by collecting, correlating, and identifying threats from network and host anti-malware systems, firewalls, and IDSs (Intrusion Detection Systems). The more advanced SIEMs have the capability to give additional information about an identified threat through knowledge bases or 3rd party advisories.
Tune in for tomorrow’s blog entry where I will continue the discussion by covering requirements for assessing security controls and collecting, correlating, and analyzing security information.
Why Click Fraud Matters
Spending on Internet advertising in the US alone eclipsed $10 billion in 2010. Unfortunately, online sponsored advertising has a major downside: Click Fraud. Industry rivals, or other interested parties impersonate consumers by clicking on paid ads with no intent of making a purchase. These fraudulent clicks effectively drive up a company’s advertising costs without increasing sales. Click Fraud has become such a widespread issue that in the eyes of LinkShare CEO Stephen Messer, it “could wipe out ROI in search marketing.”
Initially, advertisers placed their trust in search companies such as Google, Yahoo and Microsoft to police fraudulent clicks. In 2006, Google CEO Eric Schmidt compromised that trust when he stated:
“Eventually the price that the advertiser is willing to pay for the conversion will decline because the advertiser will realize that these are bad clicks. In other words, the value of the ad declines. So, over some amount of time, the system is, in fact, self-correcting. In fact, there is a perfect economic solution, which is to let it happen.”
His statement led many companies to question the commitment of their providers to preventing Click Fraud.
At the heart of Click Fraud is the act of simulating a click. This is accomplished through multiple means. The simplest is to employ individuals who spend their time clicking on ads without ever purchasing an item. This act is both costly and time consuming if done inside the United States. In developing countries, this is not the case. In the words of Nir Kshetri, the fraudster “must often decide to employ the seemingly bottomless source of human clickers in developing countries, or use technology.” Kshetri goes on to point out that employing human labor becomes less attractive as PPC providers and advertisers become more adept at employing invalid click detection. Because the IP address of a human clicker is usually consistent, PPC providers can easily block traffic from it.
Another method for performing fraud is to write a program that simulates clicks. To do this, the program must perform many tasks normally undertaken by a web browser. The program must first execute JavaScript code to retrieve the HTML code of a web advertisement. It then parses the HTML code for links and sends an HTTP request to the advertiser’s web server. Since this type of fraud is simple to detect, the perpetrator must distribute the program across the Internet using a botnet. The botnets find their way onto unsuspecting users’ computers through many means. Tempting offers of free software, games or other goods from illegitimate websites lure many consumers into loading botnets unknowingly. Computers can also be infected by visiting legitimate websites that have been compromised by Click Fraudsters.
Unlike many other online crimes, Click Fraud has no offline counterpart. One impact of Click Fraud is that the legal system has not been able to keep pace with it. Online crime is growing at a rapid rate that legislators have been unable to match. Adding to the problem is a lack of regulation across borders. While new antifraud laws are slowly being passed in the United States and the European Union, other countries have little or no regulation. In India in 2006; for example, advertisements looking to hire people to click on ads ran in national newspapers.
As an industry, online advertising is not going away anytime soon. Click Fraud will not be going away either. Given my background in law, it is obvious to me that just like with other legal issues regarding technology, legislators cannot keep up with the rapid pace with which Click Fraudsters change their tactics. Add in the challenges of enforcing laws across international borders and the problem becomes even direr. It is therefore obvious that legal changes will not come soon, so other methods are necessary. With legal recourses lagging behind, it is up to industry to find ways to protect itself.
Twitter: To log or not to log: Is that the question?
As Twitter continues to thrive as the communications tool of choice amongst activists, dissenters and occupiers worldwide it should be no surprise that the San Francisco-based company is drawing heightened attention from US law enforcement agencies. Most recently, and likely to the surprise of even the most conspiratorial privacy advocates has been the Boston Police Department’s subpoena for data on a hashtag, #bostonPD. Yes, a supeona on a hashtag.
While Twitter has fought back against law enforcement agencies’ attempts to get their hands on user data in the past, it seems to be losing more than its winning. Twitter’s defiance towards LEAs has been its policy to notify users when their accounts have been subpoenaed, a policy that LEAs have sought to bypass.
This attention from LEAs has lead WikiLeaks to recommend a seemingly elegant solution: 
With the support of WikiLeaks the #NOLOGS hashtag is catching on quickly. No surprise there. as from an activist’s perspective this seems like a winning move against the ever-growing Big Brother state. The question that needs to be asked though is, would this actually provide the protection that activists are looking for and need? Also, probably more importantly, what kind of effect would a switch to a #NOLOGS policy have on Twitter’s 140 character worldwide conversation?
First let’s look at Twitter’s Privacy Policy to see what they Log:
Log Data: Our servers automatically record information (“Log Data”) created by your use of the Services. Log Data may include information such as your IP address, browser type, the referring domain, pages visited, your mobile carrier, device and application IDs, and search terms. Other actions, such as interactions with our website, applications and advertisements, may also be included in Log Data. If we haven’t already deleted the Log Data earlier, we will either delete it or remove any common account identifiers, such as your username, full IP address, or email address, after 18 months.
And what that data is used for:
Law and Harm: We may preserve or disclose your information if we believe that it is reasonably necessary to comply with a law, regulation or legal request; to protect the safety of any person; to address fraud, security or technical issues; or to protect Twitter’s rights or property.
From a logging perspective it’s important to consider the amount of data we are talking about here. Twitter claims to have 175 Million users, a statistic that some debate. However, from a logging perspective it matters not if the account is fake or real, they are still getting logged. Regardless of how this data is compressed and stored, this is a LOT of data, every single day. While the average tweet is only 140 characters, when you count the included metadata (IP, Location, Date, Time, browser type, the referring domain, pages visited, your mobile carrier, device and application IDs, and search terms) we are talking about a massive amount of log data. From a management perspective this is a lot of work. Storing and accessing that volume of data is likely not as easy as many would think and from that perspective alone it would seem like Twitter would love to adopt a #NOLOGS policy.
However, if we dig a bit deeper into what this data may also be used for, beyond incriminating journalists and activists worldwide it would seem like the chances of this ever happening are slim. According to their Privacy Policy, log data is also used for Fraud, Security and Technical reasons.
Consider that account X is being reported as spam by a high percentage of users, why not cross reference the IP address its been connecting from (or even address block) to other accounts recently being flagged as spam? Simple algorithms like this could potentially be an integral part of keeping Twitter safe and usable. It would certainly seem like sites like Facebook are using similar systems to thwart fraud as well. Consider the following screen shot, captured after Facebook detected malicious activity.
Beyond fraud and security data, it’s hard to imagine that Twitter is not capitalizing off visited link data as well. If that’s the case, adopting a #NOLOGS policy could potentially have financial implications for the company.
It would seem like Twitter understands the situation, and the ferocious opposition that can be felt when privacy is sacrificed for security, but should the question be around Twitter’s logging policy or the US LEA’s desire to be omnipresent?
Either way, it will be interesting to see if the #NOLOGS hashtag trends on or if this mission loses steam and is forgotten. While the privacy of its activist user base is clearly important to Twitter, when you weigh in all options it seems unlikely that they will adopt such a policy.
If Twitter does remain the activist’s communication tool of choice, one thing is clear: it will be increasingly difficult to appease both US LEA’s and the activist/privacy-supporting section of its user base.
Enhance your audit trail logging with TCPWrappers
TCPWrappers performs access control for supported applications when making connections over a network. It also logs this activity to syslog, enhancing the audit trail for hosts running TCPWrappers.
While most UNIX-based distributions these days already come with TCPWrappers, there are some circumstances where one or more servers do not have this feature. If you discover that this feature isn’t installed or utilized, you should consider adding it to ensure that your audit trail logging to syslog is capturing these log messages.
TCPWrappers uses hosts.allow and hosts.deny to control what user, hosts, and/or IP addresses or networks can establish a connection to the respective service/daemon and this activity is logged to syslog. Some programs weren’t compiled to support TCPWrappers and others originally didn’t but have now adopted this functionality.
The severity and facility are all configurable via the main configuration file or within the 2 access control files noted above. The logging level and facility can be set for all services or individually.
Besides logging all the interesting messages, there is a simple and nifty way to monitor access attempts when the service isn’t enabled. That is to have the service/daemon referenced, but to execute /bin/false so that the access attempt is logged, but nothing is executed or no connection is established.
If UNIX-based systems are a part of your critical/sensitive infrastructure, review each system for the existence of TCPWrappers. If it doesn’t exist you should consider adding it and if it does, make sure that all programs that can use TCPWrappers are configured to do so. And, of course, now that this information is logged to syslog, ensure you review these logs for any security, audit, or operational activities that require extra attention or analysis.
LogRhythm wins "Innovator of the Year" from SC Magazine. "This is not your father's log manager."