Before you answer those questions, you first need to understand why some 560,000+ Internet users around the world will be knocked offline.

In November 2011, the FBI arrested two Estonian cyber criminals who successfully re-routed internet traffic to sites they controlled. These sites were profit centers for the criminals because the criminals were paid by advertisers a fee for every ad displayed or clicked on, and product bought by those Internet surfers who visited the controlled sites. In fact, the advertisers paid approximately $14 million dollars based on the number of people who viewed the criminals’ sites. Of course, the advertisers who paid them likely did not know the traffic was being sent to the sites; rather, they only saw the numbers of viewers, clicks and purchases.

In the world of online advertising, the number of ad viewers translates into profit. The Estonian cyber criminals in this matter understood that fact, but rather than working to build a great site, attracting legitimate users and letting the site mature over time, they took a radical and highly illegal approach. They found a way to hijack Internet traffic and route users through their sites. Their “way” was to infect computers with a malicious program dubbed DNSchanger. The DNS in this case refers to the Domain Name Server/System and it is what converts www.krolladvisory.com to the IP address 208.71.236.20.

In simple terms, when you type in a website, such as www.krolladvisory.com, your computer contacts the Internet’s equivalent of a telephone operator (or 411) and asks to be connected to the IP address attached to that name and then you are connected to the proper website. If your computer is infected with DNSChanger, when you type in the same address (www.krolladvisory.com) the “changer” contacts a private operator or (1-900) and you are then routed to a site the criminals control and from which they can make a profit. Some of these sites caused further infections, some showed you pop up ads and then redirected you, and some were fakes of popular sites.

When the FBI arrested the criminals responsible for DNSChanger, they also took over control of the “private operator/1-900” server the software contacted. The FBI, in conjunction with private cyber security groups, produced a software patch to remove the DNSChanger and set the infected systems back to normal: http://www.dcwg.org. Also, with court approval, the FBI brought in an outside group to set up legitimate DNS servers in the place of the DNSchanger system. These servers now send the “private operator/1-900” request to the legitimate “operator/411” so the user will reach the “true” site.

However, on July 9, 2012, the FBI will stop paying for those new servers and they will go offline – hence, the ominous warnings of “internet doom” in July. DNSChanger victims will need to download the patch and fix their systems or risk being knocked offline. DNSChanger’s impact illustrates a key recommendation we make to every one of our clients. Keep your computer systems patched and up-to-date with the most recent software updates. The use of a patch management system to effectively and efficiently push patches and updates to all of the systems within your IT infrastructure is recommended. Kroll also recommends that corporations then spot check those “patched” systems to see if the patch/update actually did occur. These spot checks can be run manually or through the use of vulnerability scanning software.

In short, being infected with DNSChanger isn’t great, but luckily a simple and easy-to-install patch will keep you online. 

But back to my original question: Are you one of the 560,000+ users who will be knocked offline on July 9, 2012? How do you know?

E.J. Hilbert
Managing Director
Kroll Advisory Solutions

The other, much more controversial bill is the Cyber Intelligence Sharing and Protection Act (CISPA or HB 3523). The purpose of this bill is to encourage the sharing of cyber threat intelligence information between the government and private industry. It has received strong opposition from various privacy advocates and the President has threatened a veto if it reaches his desk. The main criticism stems from the perceived lack of clarity as to what constitutes a cyber security threat, or what kind of sensitive information can be collected. The final version that passed the House did include amendments to tighten these definitions; in addition, several companies directly support the bill, citing the immediate and pressing need companies have to be able to receive timely cyber threat intelligence.

Both of these bills will now go to the Senate. We’ll keep a close eye on these, as well as several others still under consideration in the Senate.

The biggest headline of the report suggests that an increased focus on compliance has not resulted in increased security, and patient data continues to be at risk.  In fact, the report shows a steady rise in data breaches over the last six years, despite increasingly stringent regulatory activity surrounding reporting and auditing procedures, and heightened levels of compliance.

On May 2 at 2:00 p.m., Kroll Advisory Solutions and HIMSS Analytics will host the Security of Patient Data webinar, in partnership with Healthcare IT News, to review and discuss key findings of the report. Healthcare and patient data security risk experts will review the key findings in the report and will be covering ongoing and emerging issues in risk management for the healthcare industry.

Topics to be covered include:

• The changing patient data security landscape
• Best practices in patient data security
• The healthcare data security forecast for 2012 and beyond

Panelists:

• Jennifer K. Horowitz, MA, CPHIMS, Senior Director of Research, HIMSS Analytics
•  Lisa A. Gallagher, BSEE, CISM, Senior Director, Privacy and Security, HIMSS
• Brian Lapidus, Senior Vice President, Kroll Advisory Solutions
• Mike Miliard, Managing Editor, Healthcare IT News (Moderator)

We urge you to register for the webinar, as it provides a great deal of in-depth insight into the results and takes a look at some of the broader issues we’ve been seeing in the healthcare industry of late.

The study is a tool to both monitor and provide insight into the effect and effectiveness of regulatory changes and the resulting compliance efforts taking place, as well as the evolving state of patient data security. The 2008 and 2010 reports uncovered a false sense of security among healthcare organizations, causing them to overlook critical gaps in policies and procedures that put patient data at risk.

When the report is released, you’ll also have an opportunity to sign up for the webcast in May that will feature both Kroll and HIMSS Analytics experts reviewing the key findings in the study. In the meantime, don’t forget to register for the report here.

Earlier this month, we released our annual tax tips for consumers, compiled by the Kroll investigators who have dealt with countless victims of wage and tax-related fraud. We strongly urge all consumers to be vigilant with their personal information, but particularly at this time of year when vulnerability increases. It can be frustrating, confusing and even scary to discover that someone else is using your or a family member’s information to file taxes, claim job earnings, or any number of issues that can threaten your ability to properly file your taxes, claim your refund, or obtain benefits.

For example, with employment fraud, an identity thief uses another person’s Social Security number (SSN) or other Personally Identifiable Information (PII) to obtain employment. This can result in additional wages reported to the Social Security Administration, which can affect benefits eligibility (unemployment or disability), and can also cause problems with tax filing (discrepancies in earned income reported to the IRS). In this instance, tax fraud can occur in conjunction, when the identity thief uses the stolen PII while filing taxes. Or, it can occur as a separate incident, when someone simply files taxes using another person’s SSN.

The IRS has increased its effort to address tax-related identity theft over the last few years and while Kroll’s investigators have seen firsthand how this effort has assisted identity theft victims, it should be noted that victims still have an uphill battle – resolution of a tax-related issue can take up to six months. In light of how prolific this type of theft has become, and its negative impact on victims, we urge all consumers to read Kroll’s tips list and take steps to reduce the risk of becoming a victim – and learn more about how to respond appropriately if you suspect you already are a victim.

by the Kroll team

Log files are files that capture systematic events. Many are stored as text files, as XML files, or in databases. Overall the format and content of log files vary depending on the system or application that creates them. There are also settings that can be adjusted to change the level of detail that is logged, or how long event data is retained. In active environments with many users, log files could grow and consume disk storage space at an alarming rate, and thus are usually retained for distinct periods of time. In some instances, logs can be capped via a system setting (e.g., retain 10 GB of logs). In other instances, logs may be maintained for a specific duration of time (e.g., one week or 30 days).

Day-to-day, log files are typically only used and viewed by system or server administrators to perform troubleshooting in response to a system issue, such as a server crash or an application performance issue. In some cases, logs are only useful for a short period of time to administrators (i.e., for the events that occurred just before a server crash or an application failure); therefore, logging may only be retained for days or even hours. When investigating a situation that may have been going on for weeks or even months, it is critical to know what logging is/was available on a long-term basis in order to establish timelines and behavior patterns for the duration of the situation.

Every organization should have an understanding of the application logs that are generated and maintained, for how long the information is maintained before overwriting it, and what sorts of system events or transactions are logged. If a situation arises where there was a possible IP theft three months ago, or someone is suspected of fraudulent activities over the last six months, IT will need to quickly establish what logs may be useful, including how far the logs go back, and what level of detail they contain.

In order to quickly respond to incidents or investigative needs, information security and their technology partners should develop a detailed understanding of their logging capabilities, including:

1. Identify which systems or applications have logging capability, and whether logging is enabled or disabled within those systems. (Many systems have logs enabled on a limited basis or turned off altogether due to space constraints or performance concerns.)
2. Understand what level of logging detail is available, and for how long do the applications maintain log information.
3. If older logs are necessary to respond to an incident, determine if the log files are backed up with the applications (logs are seldom backed up due to space constraints and administrative overhead required to back up many files or large log files).
4. If the number of logs becomes unwieldy, consider implementing a log aggregate (syslog). This can compile logs from many different areas into one location. Consider including the syslog in your existing enterprise backup solution.

If organizational information security groups and/or technology teams are prepared with this information, it can save valuable time at the onset of an incident, and allow the response team to react quickly and analyze facts in an investigation.

by John Connell,

John Connell is a director for the Cyber Security & Information Assurance practice of Kroll, where he assesses client needs related to digital investigations, intellectual property protection, information management and retention, and electronic discovery.

Acquiring and analyzing logs are critical with incident response and it is highly recommended that corporations address log management in a proactive manner. Log management is one component of an organization’s Security Incident and Event Management (SIEM). There have been many companies that Kroll has assisted with intrusion incidents in which the smoking gun could have been identified if system logs were being obtained and stored appropriately. I view system logs the same way that my friends in physical security view the ubiquitous surveillance cameras that seem to be popping up everywhere. Without the cameras, it is impossible to “see” what happened. System logs are no different. Additionally, outside of incident response, ensuring system logs are being obtained and analyzed appropriately is also extremely important for employee accountability and identifying trends/anomalies at the system level.

When implementing log management, it is important to ensure that at a minimum logging is enabled on all critical production systems. It is also worthy to implement logging in development environments. This is especially true if production data is being copied into the development environment for testing purposes (it is not recommended to copy production data into the dev environment unless the data is first sanitized! But that is another story…).

For cyber investigations, one of the most critical investigative trails is that of IP addresses. Because of this, be sure to log the IP address and respective date and time associated with each log entry/event. This will also be important if your cyber incident escalates to law enforcement action. One of the first items that law enforcement will request is the IP addresses. An incorrect date, time, and/or time-zone associated with the captured IP address could result in a search warrant being executed at the wrong house, so the accuracy of system logs is tantamount to a successful investigation.

Ensuring that you are retaining system logs is a logical first step in strengthening your information security posture. This giant pile of system logs are excellent to have for reactive purposes. But, wouldn’t it be nice if you could proactively monitor your logs that are otherwise sitting around gathering dust? There are numerous SIEM software applications on the market that do just that. If a baseline can be set on what is “normal” in your particular environment, the software can be set to alarm if specific thresholds are met. It should be noted that the canned queries, reports and alerts from the out-of-the-box SIEM solutions will need to be customized for your particular environment and the unique threats that you face. Kroll does not recommend or endorse specific software solutions, but feel free to Google for “Log Management Software and Analysis” (or Yahoo! for that matter… we are also search engine indifferent at Kroll!).

by Theodore Theisen

Theodore Theisen is a director for the Information Security, Forensics and Data Breach practice of Kroll. In this capacity, Mr. Theisen provides investigative expertise, analytical assistance and digital forensic support to contribute to client success.

You may recall in a previous post discussing data breach response, I mentioned the very real threat that malware has become, as well as the forensic efforts required to reveal what information may have been breached. Here, I’d like to elaborate on what we’re seeing in the wild from a malware data breach perspective and how to defend against the threat.

The primary vectors of malware compromise we’re seeing are coming through malicious spear-phishing emails and SPAM email blasts sent to wider audiences. The emails contain malicious URLs or attachments. Hidden within them are either links to malicious downloads or scripts that somehow compromise the computer of the recipient downloading a malicious binary or payload.

Whatever is downloaded as a result often leads to super administrator access on the computer or compromise of user web browser activity. Both can lead to a situation where an attacker can remotely control the computer, and install key loggers that “sniff” user-entered web browser information, such as valuable usernames and passwords to banking and webmail accounts.

Once the computer is successfully compromised, the attackers often pilfer whatever information is available on the computer. We often see the attackers removing sensitive files on the computer including, but not limited to, sensitive operating system files containing password hashes so they can crack passwords for other users who have logged on to the computer previously. The usernames and passwords are then often leveraged by the attacker to log on to other computers and resources on the network or even establish other backdoors into the organization such as remote desktop access or by VPN connections.

In other more unfortunate scenarios, we’ve seen this type of compromise lead to data exfiltration, or removal, of sensitive data types on the computer. Data types we’ve seen removed often include regulated data, such as credit card data or Protected Health Information (PHI). In some cases we have seen this information shared on malicious locations and IP addresses on the Internet. Some indicators of this type of activity are often found in system log files, file system meta-data, and malicious binaries downloaded onto the computer, but they often don’t leave a trace of what may have been removed due to their sophisticated methods and advanced understanding of common computing operating systems.

You might ask, “Why doesn’t my anti-virus software detect this activity?” Attackers are getting more advanced in their obfuscation techniques, such as file packing, to trick corporate email detection and computer anti-virus software. Also, some malware is so sophisticated that it may never even be saved persistently on the computer, but it may only run in memory.

Sometimes the targeted machines are core infrastructure computing information assets that store customer or employee databases, thus potentially creating a data breach situation that might require notification. Forensics on the compromised computer and malicious binaries can often better identify the breach population, sometimes reducing the total number of individuals that must be notified.

With this type of sophisticated threat, how does an organization keep up with the threat?

• Segregate more vulnerable or uncontrolled computers from network segments containing sensitive information and limit their ability to communicate with one another.
• Layer your malware defenses with different malware vendors and protection mechanisms.
• Monitor your network. Review your intrusion detection appliances’ logs at points of egress and internal core segments across the wide area network (WAN). Full packet capture is an emerging defense to “replay” the exfiltration and remote activity.
• Training! Give your employees specific guidance on secure computing. Let them know of the threats on the Internet, and those specific to the organization.
• Consider additional defenses to protect user activity such as advanced web content monitoring devices.
• Conduct a risk assessment to address the threat likelihood against your organization, identify the potential business impact, and insure that sufficient safeguards are in place.
• Consider encryption of sensitive data such as credit card numbers stored within a database. If the data is compromised the encryption might mitigate notification needs.

by Luke Tenery,
Luke Tenery, CISA, CISSP, GPEN, is a Director in Kroll’s Cyber Security & Information Assurance practice. He specializes in proactive information security assessments and data breach response.

The regulation also expands data breach notice requirements to cover all industries rather than just telecoms and ISPs under the current Directive.  The breach notification requirements provide some detail, but still leave important points such as the format and methods of notice up to future acts.  The regulation requires notice of data breaches to the supervisory authority within 24 hours of an organization becoming aware of the breach, if feasible.  The supervisory authority is the Data Protection Authority (DPA) in the nation where the organization has its main establishment.  If notice to the DPA is later than 24 hours, the organization must provide a “reasoned justification” for the delay.  Notice to the DPA must:

• Describe the nature of the breach, including number and categories of personal data and individuals involved;
• Provide the name and contact information of the data protection officer or other contact where more information can be obtained;
• Recommend measures to mitigate potential adverse effects of the breach;
• Describe the consequences of the breach; and
• Describe the measures proposed or taken to address the breach.

Notice to individuals is required when the breach “is likely to adversely affect the protection of the personal data or privacy of the data subject.”  The regulation does not provide guidance on how to apply this standard, but instead leaves that for future acts.  The format and method of notice are also to be determined in future acts, but the regulation specifies that notice to affected individuals must:

• Describe the breach;
• Provide the name and contact information of the data protection officer or other contact where more information can be obtained; and
• Recommend measures to mitigate potential adverse effects of the breach.

Notice to individuals must be provided “without undue delay.”  However, notice is not required if the organization demonstrates to the satisfaction of the DPA that it applied technological measures rendering the data unintelligible to unauthorized individuals.   This again emphasizes the importance of encrypting personal data.

The regulation’s 24-hour notice requirement to DPAs is likely to be difficult for organizations to comply with.  The final draft added “if feasible,” which was absent from a prior version, reflecting the EC’s acknowledgement that in some cases this will not only be difficult, but impossible.   We’ve seen spirited debate among privacy professionals on whether the regulation will be passed as-is or softened significantly.  Any predictions?  We would love to hear them.

By Francesca Wolf
Legal Counsel & Compliance Officer

• The sensitivity of the breached personal data;
• The number of individuals affected by the breach; and
• Whether the breach or pattern of breaches demonstrates a “systemic problem.”

Notice to individuals would be required if it is “reasonable” under the circumstances to “believe that the breach creates a real risk of significant harm to the individual.” Significant harm includes, but is not limited to, “bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss, identity theft, negative effects on the credit record and damage to or loss of property.” When determining whether there is a real risk of significant harm, organizations are instructed to consider the sensitivity of the personal information involved and the “probability that the information has been, is being, or will be misused.”

The bill requires that the notice to individuals contain sufficient information for individuals to understand the importance of the breach and take steps to protect themselves. Additional content requirements are yet to be determined and may be imposed via regulations. Unlike U.S. breach notice laws, the bill does not mandate particular methods of notice. It simply requires that the notice be conspicuous and given directly to the individual if feasible to do so. The timeframe for notice is “as soon as feasible” after a breach is confirmed and it is determined that notice is required.

It’s uncertain at this point whether the bill will gain traction. The same legislation was introduced last year, but failed to make it past a second reading. We will watch to see if this is finally the year for breach notice in Canada.

By Francesca Wolf
Legal Counsel & Compliance Officer