Lenny Zeltser on Information Security

5 Favorite Security Reads of the Week

Sat, 19 May 2012 09:25:17 -0400

Here’s a listing of my 5 favorite on-line security articles, papers and blog posts that I read in the past week:

Why the Public Cloud Shuns Security by Branden Williams
SEC Guidance Is a Really Big Deal by Richard Bejtlich
How Long Until Apple iOS Needs Its Own Patch Super Tuesday? by Mark Kelly
Cyber Espionage & Strategic Web Compromises by Steven Adair and Ned Moran
Why Info Sec Position Go Unfilled by Lee Kushner

Also, during the past week I published the following posts:

Looking forward to next week!

For more recommendations, see my earlier security reads of the week.

— Lenny Zeltser

How Malicious Code Can Run in Microsoft Office Documents

Thu, 17 May 2012 10:37:00 -0400

One of the most effective methods of compromising computer security, especially as part of a targeted attack, involves emailing the victim a malicious Microsoft Office document. Even though the notion of a document originally involved non-executable data, attackers found ways to cause Microsoft Office to execute code embedded within the document. Below are 4 of the most popular techniques used to accomplish this.

VBA Macros

Support for executing code that’s embedded as a VBA macro is built into Microsoft Office. Once the victim opens the document and allows macros to run, this code can run arbitrary commands on the user’s system, including those that launch programs and interact over the network. The penetration testing tool Metasploit makes it relatively straightforward to generate payload that attackers could embed in an Office file as a VBA macro. (See one example by Chris Patten.)

Such macros can be included in “legacy” binary formats (.doc, .xls., .ppt) and in modern XML-formatted documents supported by Microsoft Office 2007 and higher. In either case, Office will present the user with a security warning, stating that macros have been disabled and offering to “enable content.” Social engineering techniques can persuade the victim to click the button that will allow the embedded macro to run and infect the system.

Payload of a Microsoft Office Exploit

Another way to execute malicious code as part of an Office document involves exploiting vulnerabilities in a Microsoft Office application. The exploit is designed to trick the targeted application into executing the attacker’s payload, which is usually concealed within the Office document as shellcode.

In this case, Microsoft Office has to be exploited to execute the attacker’s code. This is in contrast to the previous scenario, where the attacker takes advantage of macros, supported by Microsoft Office as a feature. For instance, vulnerability CVE-2012-0141, announced in May 2012, could allow the attacker to craft a malicious Excel file to include an exploit that would “take complete control of an affected system.”

Embedded Flash Program

Embedding a Flash program inside an Office document provides attackers yet another way to run malicious code on the victim’s system. In this case, the code within the Flash object run as soon as the victim opens the document without any warnings and without relying on exploits. This code is till subject to security restrictions imposed by Flash Player, so to perform escalated actions the code would need to exploit a vulnerability in Flash Player.

One example of this attack has been described by Mila on the Contagio blog. The malicious Word document “DOC Iran’s Oil and Nuclear Situation.doc” was sent to a victim as part of a targeted attack. The document contained a Flash object, as seen below. (See steps to manually embed a Flash object in an Office document.)

Attackers can embed Flash objects in Office documents using automated tools. manual steps to do this the Flash object instructed Flash Player to download and play an MP4 file that was designed to exploit the CVE-2012-0754 vulnerability in Flash Player, announced in February 2012. This allowed the attacker to infect the victim’s system with a malicious Windows executable (trojan).

Embedded JavaScript

Another way to automatically execute code then the victim opens a Microsoft Office document involves embedding the ScriptBridge ActiveX control in the file. This control allows the attacker to embed and execute JavaScript, as was the case with the malicious “World Uyghur Congress Invitation.doc” file I obtained from the Contagio blog. This file used the “Microsoft Scriptlet Component”, implemented as the ScriptBridge ActiveX control to execute the embedded JavaScript code.

This Word file used ScriptBridge to execute embedded JavaScript code, which downloaded a malicious Flash file by from the specified URL. Microsoft Office automatically invokes embedded ActiveX controls that are marked Safe-For-Initialization, which is the case with ScriptBridge. (I’d love to better understand how ScriptBridge is being used to run JavaScript, so if you have more details, please let me know.)

In the case of this Word document, the downloaded Flash file was crafted to exploit the CVE-2012-0779 vulnerability in Flash player, announced in May 2012.

These are some of the techniques that intruders have used to execute code in Microsoft Office documents to compromise the system. The attacker could directly take advantage of a vulnerability in the targeted Office application. In other cases, the attacker uses functionality provided by Microsoft Office to either trick the user into allowing the malicious code to run (VBA macros) or to use a weakness in Office settings to run code that exploits vulnerabilities in other applications (Flash Player).

— Lenny Zeltser

Confusing the Padlock and the Favicon in the Web Browser

Sun, 13 May 2012 10:02:00 -0400

Web browser makers are continuing to change how they display two visual elements that people have been taking for granted: the padlock that designates an HTTPS connection and the favicon that acts as the thumbnail of the website’s visual identity. These changes are aimed at helping to minimize the risk that a favicon that looks like a lock might instill a false sense of security.

Users of web browsers have gotten accustomed to looking for the padlock image as part of the URL to determine whether the connection is “secure.” The browsers have typically displayed the lock for HTTPS connections where the SSL certificate was properly validated. Most non-geeky people don’t know what aspect of security the lock is supposed to signify, but they have been trained to rely on it as a symbol of online safety.

Webmasters can specify favicons as tiny images that web browsers have displayed in the URL bar to reinforce the site’s digital identity. Unfortunately, computer attackers can display favicons that look like padlocks, fooling victims into thinking that they were using an SSL-encrypted and authenticated connection. One tool that can automate such an attack is sslstrip, and this category of attacks is described in the Black Hat presentation by the tool’s author.

Internet Explorer

Microsoft’s Internet Explorer (v9) displays both the padlock and favicon in the URL bar. The favicon is on the left of the URL and—assuming the connection is using HTTPS with a valid certificate—the padlock is on the right:

A malicious webmaster or an attacker who can interfere with the web session may be able to display a padlock favicon even for HTTP or an invalid HTTPS connection, fooling the victim into thinking that the connection is “secure.” The distinction of where the trustworthy lock should exist in Internet Explorer (to the right of the URL, not to the left) is likely to be lost on most people.

Google Chrome

Google Chrome doesn’t display the favicon as part of the URL, showing it only in on tabs and bookmarks. Chrome displays the lock icon in the URL bar (in several variations) for connections that use HTTPS.

Because Chrome doesn’t display the favicon on the URL bar, this browser’s users are being conditioned to place greater trust in the padlock image displayed next to the URL. This is good.

Firefox

Mozilla’s Firefox stopped displaying the padlock icon for HTTPS connections starting in version 4 of the browser, phasing it out in favor of the Site Identity Button. The current production (v12) and beta (v13) releases of Firefox still display the favicon the browser’s URL bar and on the tab:

In this setup, a website that doesn’t use HTTPS display a favicon that looks like a padlock in the URL bar, fooling the victims who associate the lock with safety into thinking that the connection is “secure.”

To help address this risk, the current nightly build of Firefox (v14) no longer displays the favicon in the URL, showing it only on tabs, bookmarks and Awesome bar suggestions, according to Firefox developer Jared Wein. This version of Firefox adds the padlock to the Site Identity Button, while preventing webmasters from placing a false lock icon in the URL bar:

The approach to eliminating the favicon from the URL bar and displaying the padlock there for valid HTTPS connections is consistent with the behavior of Google Chrome. It’s encouraging to see the two browsers using compatible visual approaches that are designed to minimize user confusion.

Opera

Fortunately, the behavior of Opera is consistent with how Firefox and Chrome display locks and favicons. Opera displays favicons on tabs and bookmarks, while displaying the padlock on the URL bar for appropriate HTTPS connections:

Safari

Unfortunately, Safari displays the padlock and favicon on the URL bar, as well as on tabs and bookmarks in a manner consistent with Internet Explorer. In other words, the favicon is displayed to the left of the URL and the lock, when appropriate, is shown to the right of the URL.

There’s room for continuing to improve the visual indications that browsers present to users for making security-related decisions. Internet Explorer and Safari appear behind times in their treatment of favicons, because they display these images in the URL bar. In the meantime, individuals who educate non-technical people in web safety practices should consider how to best explain the various security indicators in the URL bar. None of these are easy undertakings.

Hand-picked related articles:

— Lenny Zeltser

5 Favorite Security Reads of the Week

Sat, 14 Apr 2012 09:54:33 -0400

Here’s a listing of my 5 favorite on-line security articles, papers and blog posts that I read in the past week:

Security Failure Scenarios by Gunnar Peterson
Big Brother Forensics: Device Tracking Using Browser-Based Artifacts (Part 1) by Chad Tilbury
What’s RIGHT with Infosec by Dave Shackleford
Trojan moves its configuration to Twitter, LinkedIn, MSDN and Baidu by Snorre Fagerland
Thieves Replacing Money Mules With Prepaid Cards? by Brian Krebs

Also, during the past week I published the following posts:

Looking forward to next week!

For more recommendations, see my earlier security reads of the week.

— Lenny Zeltser

Slides for Presentation on Real-World Social Engineering Attacks

Fri, 13 Apr 2012 22:18:00 -0400

Slides for Presentation on Real-World Social Engineering Attacks:

I published the slides to my presentation “How attackers use social engineering to bypass your defenses,” which shows numerous examples of real-world social engineering attacks. These materials are designed to help you improve the relevance of your security awareness training and to adjust your data defenses by revisiting your perspective of the threat landscape. They cover techniques such as:

The use of alternative channels of communication
Focus on personally-relevant messages
The principle of social compliance in potential victims
People’s reliance on security mechanisms

Why bother breaking down the door if you can simply ask the person inside to let you in? Social engineering works, both during penetration testing and as part of real-world attacks. This briefing explores how attackers are using social engineering to compromise defenses. It presents specific and concrete examples of how social engineering techniques succeeded at bypassing information security defenses.

— Lenny Zeltser

Are Anxious People More Vigilant in Information Security?

Wed, 11 Apr 2012 22:43:19 -0400

Common wisdom suggests that anxious individuals are better at spotting danger than those with more mellow personalities. However, research by Tahl Frenkel and Yair Bar-Haim indicates that the opposite may be true: People with nonanxious personalities might be more skilled at spotting the early signs of trouble. This finding could highlight the type of people best suited for information security jobs.

Spotting Fearful Faces on Photographs

Some of the individuals selected for the study possessed anxious personality traits on the a State-Trait Anxiety Inventory scale, while others were nonanxious. The participants were shown photographs of a face that exhibited a progressive degree of fearfulness. The researchers measured how early in the progression the participants could detect fear on the photos.

“As expected anxious participants needed significantly less stimulus fear intensity for conscious fear detection,” researchers discovered. However, only non-anxious participants began exhibiting early signs of fear detection before consciously recognizing fear on the photograph. The Scientific American Mind’s March 2012 issue clarified:

“The brains of anxious subjects barely responded to the images until the frightened face had reached a certain obvious threshold, at which point their brains leapt into action as though caught off guard. Meanwhile nonanxious respondents showed increasing brain activity earlier in the exercise, which built up subtly with each increasingly fearful face.”

The researchers concluded that anxious people might lack the ability to detect threats in a granular manner and “therefore might face threats with no prior warning signal—further contributing to their already heightened anxiety level and perhaps associated with their enhanced baseline threat vigilance.”

Early Detection of Threats in Information Security

If there is a stereotype of an information security professional, it is sure to include anxious characteristics, such as concerns regarding threats, distrust and perhaps a degree of paranoia. These traits allow us to recognize the signs of danger, building defenses in anticipation of risks and also responding to the situation when the defenses fail.

Yet, those professionals who are calm and nonanxious might be better at spotting early warning signs of an intrusion before it escalates into a major breach. This skill is similar to the ability to detect the subtle signs of fear when looking at a photograph of a face. If this is true, then I wonder whether such individuals trust their instincts and have the time to begin investigating the potential problem early enough.

If this is interesting to you, see my earlier post Are Mistrustful Individuals Better at Information Security?

— Lenny Zeltser

4 Favorite Security Reads of the Week

Sat, 17 Mar 2012 10:03:05 -0400

Here’s a listing of my 4 favorite on-line security articles, papers and blog posts that I read in the past week. This week I’m featuring a series of articles that profile Anonymous that were written by Josh Corman and Brian Martin:

Also, during the past week I published the following posts:

The Risks of Remote Desktop for Access Over the Internet
Please transfer this email to your CEO or appropriate person, thanks (Internet Storm Center)

Looking forward to next week!

For more recommendations, see my earlier security reads of the week.

— Lenny Zeltser

The Risks of Remote Desktop for Access Over the Internet

Tue, 13 Mar 2012 14:41:44 -0400

It’s convenient to use the Remote Desktop Protocol (RDP) for accessing systems over the Internet, especially in server environments. However, exposing RDP to direct connections is risky. This setup not only gives remote attackers the opportunity to guess logon credentials, but also relies on the lack of a remotely-exploitable vulnerability in Microsoft’s RDP implementation.

Microsoft’s Security Bulletin MS12-020, released in March 2012, described critical vulnerability in Microsoft’s RDP implementation on most Windows platforms (CVE-2012-0002). This bug could allow a remote unauthenticated attacker to run arbitrary code on the affected system by sending “a sequence of specially crafted RDP packets.”

Microsoft provides a detailed perspective on the CVE-2012-0002 vulnerability in its Security Research & Defense blog, stating that even though it has no knowledge of the corresponding exploits, it believes that “an exploit for code execution will be developed in the next 30 days.”

I suspect such an exploit will appear sooner than 30 days, because of the relatively fast techniques available to attackers for reverse-engineering a patch to understand the nature of the vulnerability they need to target. Such an exploit would provide an attacker with access to targeted server environments and would enable automated opportunistic break-ins into servers and workstations that expose RDP to the Internet. Such an exploit would also be effective as part of a network worm for automated propagation across vulnerable systems.

My recommendations for handling the CVE-2012-0002 RDP vulnerability and future risks related to RDP:

Understand what systems in your environment expose RDP to the Internet. Create a plan to apply the MS12-020 as soon as practical.
Change the port on which your systems listen for RDP connection to avoid using the default TCP port 3389. Automated scanners and worms will be less likely to locate your RDP listeners on high-non-standard ports.
Consider configuring your RDP settings to use Enable Network Level Authentication (NLA) on Windows Vista and later platforms, as suggested by Microsoft.
Remember to have strong authentication for systems utilizing RDP to deal with remote password-guessing attacks.

— Lenny Zeltser

At the BSides San Francisco conference I presented with Lee...

Fri, 02 Mar 2012 13:17:00 -0500

At the BSides San Francisco conference I presented with Lee Kushner on the techniques for finding a good job in information security and on hiring strong candidates for an infosec position. Anthony Freed from Infosec Island recorded this 6-minute video with me at the event.

"I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and..."

Thu, 01 Mar 2012 14:40:34 -0500

““I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.””

- An excerpt from the Rugged Software Manifesto

5 Favorite Security Reads of the Week

Sat, 18 Feb 2012 10:06:05 -0500

Here’s a listing of my 5 favorite on-line security articles, papers and blog posts that I read in the past week:

More or Less by Dan Geer (PDF)
The SpyEye Competitive Landscape by Gunter Ollmann
Password Check by Frank Lesser
Trojan Caught on Camera Shows CAPTCHA is Still a Security Issue by Elad Sharf
Vishing: To Have Your Identity Stolen, Press One by Idan Aharoni

Also, during the past week I published the following posts:

Looking forward to next week!

For more recommendations, see my earlier security reads of the week.

— Lenny Zeltser

Why Are Executives More Prone to Accept Risks?

Thu, 16 Feb 2012 16:11:00 -0500

Information security professionals are often frustrated when their concerns regarding vulnerabilities and associated threats appear to be ignored by the company’s executives. I already discussed 6 reasons why business managers ignore IT security risk recommendations. I’d like to add a few more to the list, based on recent research into the links between power, prestige and decision-making.

High-Status Individuals Are More Trusting

In one study, Lount and Pettit researched how a person’s social status might influence the extent of trusting someone. In one of their experiments “participants were primed to experience either high or low status and then given the opportunity to send money in a trust game.” In this context, high status might be associated with the prestige of being a business executive, while another extreme of a low status might be associated with an entry-level mail room clerk.

The participants who were assigned a high status were more trusting when sending money, hoping that the recipient would return the funds. Low-status individuals were more cautious. The researchers concluded from this and related experiments that “having status alters how we perceive others intentions” to believe “that others have positive intentions toward us.” They also pointed out that:

“The possession of status can fundamentally alter our expectations of peoples’ motives toward us, and in turn, influence our initial trust in others.”

People with prestigious positions, such as executive managers, might be more trusting of others and, therefore, might be willing to accept more risks.

Power Leads to Overconfidence

In another study, Fast, Sivanathan, Mayer and Galinsky explored the links between an individual’s perception of power and self-confidence. Their research found that people who believed themselves to be powerful experienced more certainty in the accuracy of their believes and opinions. They confirmed that “power increases overconfidence in the accuracy of one’s thoughts and beliefs.” This matters in organizations because many “high-impact decisions are based on perceived precision of relevant knowledge.”

The effect of this phenomenon is magnified because not only the subjective sense of power causes people to become overconfident in their knowledge, but also “overconfident people tend to acquire roles that afford power.”

Prestige, Power And Decisions About Risk

My perspective on these findings through the lens of information security and related risks is as follows:

Executive managers experience a sense of power and prestige associated with their decision-making abilities and responsibilities.
Such individuals might be inclined to make risk decisions while being overly confident in the accuracy of their understanding of the issues.
Such individuals are also likely to be more trusting than people whose positions aren’t as prestigious.
The result is that executives might accept risks from a perspective that is too trusting or without spending enough effort to understand the issues.

So, there you have it: a few more reasons why executives are more prone to accept risks, in addition to the 6 explanations I offered earlier. You might also like to know that choice fatigue contributes to the willingness to accept risks and that sleep deprivation contributes to risk-taking behavior. We just cannot help it—it’s in our nature.

— Lenny Zeltser

An Example of SMS Text Phishing

Tue, 14 Feb 2012 11:44:00 -0500

Phishing—a technique grounded in social engineering—remains an effective way for attackers to trick people into giving up sensitive information. Potential victims can be contacted by email, fax, phone calls and SMS text messages. Below is an example of such a scam sent through SMS—a practice sometimes called smishing.

In this case, the recipient is requested to visit update.vtext02.net to update account information, supposedly so that he or she can continue using Verizon services.

The phone number of the SMS message’s sender was most likely spoofed.

The malicious domain vtext02.net appears to have been shut down by its registrar several hours after the phishing text message was received. When it was still active, the victim visiting the link on the SMS message would have seen the following page that mimicked the Verizon Wireless website:

All elements of this page were unclickable images with the exception of the form that prompted the victim for his or her Verizon account credentials. The “Sign In” button would submit the data to the phisher’s server-side confirm.php script. Here’s an excerpt from the page’s HTML code:

A similar incident was publicly described by another person about a month earlier. In that case, the sender was being directed to another malicious URL. The phishing SMS message stated “V.erizon.wireless.update. Please click on http:// verizon.vtext-1.com and proceed.” (Don’t go there.)

Mobile phone users are especially vulnerable to social engineering scams. One of the reasons for this, as pointed out by ESET’s Randy Abrams, is that “virtually none of the visual indicators that help even a moderately savvy novice computer user make informed decision are present on mobile devices.”

Russ Klanke documented the steps for reporting a suspicious SMS message to the GSMA Spam Reporting Service by sending a text to short code 7726 (SPAM).

Hand-picked related articles:

— Lenny Zeltser

The Role of a Resume in an IT Job Search

Tue, 07 Feb 2012 13:48:00 -0500

Although people tend to rely too much much on a resume during an IT job search, having a strong resume is still necessary for many job applications and candidates. In my mind, the goal of a resume is primarily to get past the initial screening, which is often conducted by an HR representative or a recruiter.

A good resume allows the candidate to reach the hiring manager and start deeply engaging in the discussions related to the position. This means that having a strong resume is important, but it is just one of many ways in which the candidate will need to demonstrate that he or she is a good match for the job.

The most common mistake I’ve seen on resumes is the candidate merely listing the tasks he or she performed at an earlier job. However, this listing doesn’t stand out. Make sure that every bullet point on your resume answers the question “So What?” That means including not only the text that describes what you were working on, but actually stating what you accomplished. The goal is to have the reader read the accomplishments and exclaim, “Wow! I want this person to do the same for me!”

I encourage people to think beyond the resume when they look for jobs. The standard resume format is designed to make the candidate much like everyone else in the field. On the other hand, if your reputation precedes you, or if you establish rapport with the hiring managers—perhaps even before there is even a job opening—you’ll be ahead of your competition for the position.

Also, consider the extent to which the position you’re pursuing contributes towards your career growth. Make sure that your resume and subsequent conversations make this clear to the hiring manager and other decision makers. When deciding upon your goals, think outside the standard career path that takes engineers towards management. Some individuals might be happier and achieve more professional laurels if they dig deep into one or more technological areas, rather than giving up their technical skills to manage people.

Lee Kushner and I will be presenting a talk about different perspectives on InfoSec hiring and recruiting at the B-Sides San Francisco conference in February 2012. Stop by if this interests you. Also, along these lines, I’m looking to hire a strong software development manager in Dallas; know anyone?

— Lenny Zeltser

Hiring a Software Engineering Manager in Dallas, TX

Sat, 04 Feb 2012 20:51:00 -0500

Update: This position has been filled.

I’m looking for a software engineering manager to join my team at NCR in Dallas, TX. The person supervises the team’s activities, motivating team members and instituting processes for Agile-inspired development practices. The manager is responsible for the team meeting its commitments and works closely with the team’s technical lead to support a growing number of development projects tied to business growth.

Some of the required skills and proficiency levels include:

Experience managing a software engineering team
Past experience developing applications using C, C++, C#/.NET or Java is a plus
Experience in overseeing the development of mission-critical software projects from design to completion
Strong understanding of Agile-inspired software development approaches
A cultural fit that allows the person and the team to have fun and be productive

Are you such a person or do you know someone like this? I’d love to hear from you.

— Lenny Zeltser

Who Was The First To Use The Term Exfiltration?

Fri, 03 Feb 2012 02:05:00 -0500

Information security professionals seem to use the word exfiltration with increasing frequency. However, it remains a relatively geeky way of referring to the process whereby data leaves a compromised network. That’s why I was surprised to see VeriSign use this term to describe its 2010 data breach in a 2011 SEC filing when saying, “Information stored on the compromised corporate systems was exfiltrated.”

First Use of Data Exfiltration with the SEC

VeriSign isn’t the first company to introduce the term exfiltration into SEC documentation in the information security context. As far as I can tell, the first mention can be attributed to SRA International. SRA’s May 11, 2009, 10-Q statement mentions several malware infections identified by the company’s IT and security staff. It continues:

“While we have not determined that specific information was exfiltrated, our forensic analysts suggest that the virus was designed for this purpose and, based on indirect evidence found, there is the possibility that data was compromised.”

These were probably the incidents that prompted SRA to file a notice with the Maryland Attorney General and notify its employees and customers of the breach in January 2009.

Origins of the Term Exfiltration

Oxford English Dictionary defines exfiltrate as:

Withdrawing “(troops, spies, etc.) from a dangerous position.”

It also refers to exfiltration as the “action or process of filtering out” and points to a geological book published in 1866 by P. H. Lawrence. In it, the author states:

“The opal is a product of exfiltration from the rock in or near which it occurs.”

The first mention of the term in the context of information security that I could find dates to the unclassified NSA paper published in 2002 and titled Microsoft Office 2000 Executable Content Security Risks and Countermeasures. It explains:

“Customizations with VBA or ActiveX provide a powerful programming capability within Office applications. An attacker can write a wide range of attacks from altering system settings and exfiltrating information to dangerous denial of service attacks such as deleting all files on a hard drive.”

Do you know of earlier uses of the term exfiltration, especially when used to discuss data breaches? I’m curious.

— Lenny Zeltser

Some Facts and Conjecture About the VeriSign Data Breach

Thu, 02 Feb 2012 15:43:00 -0500

The web is abuzz with stories about the 2010 data breach that VeriSign reported in its Oct 28, 2011, 10-Q statement. The document devotes a couple of paragraphs to the breach and includes the following:

“In 2010, the Company faced several successful attacks against its corporate network in which access was gained to information on a small portion of our computers and servers. We have investigated and do not believe these attacks breached the servers that support our Domain Name System (‘DNS’) network. Information stored on the compromised corporate systems was exfiltrated.”

VeriSign further explains that its information security team detected and responded to the incident. That in itself isn’t a big deal, as successful attacks occur on regular basis among companies large and small. If this were the full the extent of the situation, it wouldn’t be worth including in as part of the 10-Q filing. SEC disclosure guidelines published in October 2011 state that companies “should disclose the risk of cyber incidents if these issues are among the most significant factors that make an investment in the company speculative or risky.”

VeriSign’s mention of the breach in 10-Q implies that the incident was significant, probably because of the kind of data that was compromised. This theory is supported by VeriSign highlighting that although it “is unaware of any situation in which possibly exfiltrated information has been used, we are unable to assure that such information was not or could not be used in the future.”

VeriSign’s disclosure further states that “given the nature of such attacks, we cannot assure that our remedial actions will be sufficient to thwart future attacks or prevent the future loss of information.”

This description sounds like the company believes they were dealing with an APT-style attack. One of the characteristics of APT incidents is that it is very difficult to remove the adversary’s presence from the corporate network. Such efforts may take years and tend to be very expensive.

There is much conjecture regarding what occurred at VeriSign, given how few details the company released to the public. My hope is that VeriSign will do a better job than RSA did at providing a frank and comprehensive explanation of the affected products or services in a timely manner.

Other articles about the 2010 VeriSign breach from across the web:

Key Internet Operator VeriSign Hit by Hackers by Joseph Menn
VeriSign Hacked, Data Stolen by Darren Pauli
VeriSign Hit by Hackers by Bill Brenner

From a more general perspective, I suspect we’ll be hearing more about such breaches due to the relatively recent guidelines published on breach reporting by SEC. How many large critical infrastructure haven’t been compromised at this point? How many of them actually know that this has happened?

— Lenny Zeltser

Anticipating The Future of User Account Access Sharing

Fri, 27 Jan 2012 22:37:00 -0500

We might learn what the future holds for information technology by observing how teens use IT. After all, a decade or so from now, today’s teenagers will be consuming, influencing and creating a significant portion of IT products and services. In this note I’d like to consider how today’s use of shared user accounts among teens might influence our future access restriction practices.

User Account Access-Sharing Among Teens

A recent New York Times article by Matt Richtel discusses teens’ customs of “sharing their passwords to e-mail, Facebook and other accounts. Boyfriends and girlfriends sometimes even create identical passwords, and let each other read their private e-mails and texts.”

Exchanging something as intimate as logon credentials is a way of expressing affection for each other, Matt explains. This is also a way of expressing trust for each other, because of the potential for the person misusing access if the relationship goes sour. The article references Sam Biddle from Gizmodo, who called password-sharing “a lynchpin of intimacy in the 21st century.”

In a blog posting on this topic, danah boyd, who researches teenagers’ social media use, likens access sharing among teens to giving out one’s school locker combination to friends. She also references a study by Pew Internet & American Life Project, which found that “roughly one in three online teens (30%) reports sharing one of their passwords with a friend, boyfriend, or girlfriend.” Such practices are the result of “parental online safety norms,” says danah. She elaborates:

“With elementary and middle school youth, this is often a practical matter: children lose their passwords pretty quickly. Furthermore, most parents reasonably believe that young children should be supervised online. As tweens turn into teens, the narrative shifts. Some parents continue to require passwords be forked over.”

User Account Access Sharing Among Adults

In reality, adults frequently share user account access as well, though our practices are tinted by the guilt of violating modern societal norms and corporate security policies:

You might give our colleague a password to the accounting system, so she can perform business-critical duties while you’re on vacation.
You might store shared Administrator account password in a spreadsheet on the internal IT team SharePoint site.
You might borrow your spouse’s iPhone when running out for an errand, because you cannot find your own in the rush to leave.
You might allow your friend to login to your Netflix account to share the joy of legal Internet movie streaming.
You might be privy to our parents’ email account passwords, so you may help make sense of the data overwhelming their inboxes.

Implications for the Future of Information Access

Societal norms are continuing to adjust, as information systems gain a more profound presence in our lives. Teens are at the forefront of this change, because they have grown up in the world where computers, mobile devices and the Internet is everywhere. Their account-sharing practices, when compared to the limited but still significant sharing among adults, suggest that we’ll become more accepting of sharing account access.

What does this mean for information technology and security professionals? Nothing for the short-term horizon, as these changes will be gradual. But there will be an increasing need for tools, applications and policies that support shared access in a way that somehow provides an element of privacy or auditability. Here are a few examples of what we have today to illustrate that we are already moving in that direction:

Gmail allows its users to delegate access to their email accounts.
HTC’s Sense 4.0 phone supports Guest Mode, which restricts “what can be accessed if someone else is browsing their device.”
Several password vault products support shared access to logon credentials in an enterprise environment.
Facebook allows its users to recover forgotten passwords with the help of their friends.

What form will shared access controls take ten years from now? I don’t know, but I bet it will be more more elaborate and sophisticated than what we have today.

What learn more about the future from teenagers? Here are a few tips:

— Lenny Zeltser

Dealing With The Illusion of Invulnerability in Information Security

Sun, 22 Jan 2012 22:53:56 -0500

People overestimate their immunity to threats in many situations. One such example is discussed in a research paper by Grant and Hofmann, which explores how to motivate hand hygiene among healthcare professionals. Their findings might apply to other areas where individuals experience the illusion of invulnerability, including information security.

According to the researchers, doctors and nurses to wash their hands only half as often as recommended. This is, in part, due to the feeling that they are not vulnerable to disease. This might be because when people get sick, it’s not clear that poor hygiene is the culprit. It might be easier for individuals “to recall instances in which they failed to wash their hands without getting sick, but difficult for them to recall episodes in which failing to wash their hands made them ill.”

Two Versions of Hand Hygiene Signs

Grant and Hofmann’s paper describes a common way of motivating healthcare professionals to wash hands by posting signs that say:

Hand hygiene prevents you from catching diseases.

As you might expect, the illusion of invulnerability renders this approach relatively ineffective. However, researchers found that changing a single word in the sign significantly increased the rate of washing and sanitizing hands:

Hand hygiene prevents patients from catching diseases.

“You” was changed to “patients.” Researchers explain that healthcare professionals were more motivated by messages highlighting consequences to others, rather than to themselves because:

“Whereas people tend to overestimate their own invulnerability, for both motivational and cognitive reasons, they are less susceptible to this bias when estimating the vulnerability of other people.”

Explaining Vulnerability With Respect to Others

Following this logic, we might be more effective at influencing people’s information security practices by highlighting the risks to others, rather than to the individuals receiving the message.

If you are in the position to research the effectiveness of security awareness practices, consider explaining how weak security practices might expose customer data or how one’s infected system might be used to attack other victims. This might apply to selling or marketing information security products and services as well: Don’t pay attention to security for your own sake—do it to protect your clients, family members, friends, or even strangers.

The Illusion of Invulnerability Among Professionals

Shouldn’t healthcare professionals, who are knowledgeable about disease, wash their hands more often? It turns out, that they might actually be more susceptible to the illusion of invulnerability than laypersons. According to the paper, overestimating one’s immunity may be necessary “to maintain a sense of security while working in hazardous environments.” Convincing themselves that they are protected allows doctors and nurses to perform their jobs.

Could a similar dynamic apply to information security professionals, who deal with data breaches and computer attacks on regular basis? We become desensitized to such incidents and, perhaps, exercise less caution than would be prudent to protect our own information resources. How many infosec pros don’t follow their own advice about selecting passwords, restricting access or monitoring for suspicious activities? Truly, I don’t know, but I suspect more than care to admit.

Hand-picked related posts:

— Lenny Zeltser

"2012 may well become known as the year the criminal underground started getting a clue about how to..."

Wed, 18 Jan 2012 13:00:00 -0500

““2012 may well become known as the year the criminal underground started getting a clue about how to better index and use all of its stolen data.””

- Brian Krebs, discussing the search engine that “aggregates data about compromised payment cards, and points searchers to various fraud shops selling them.”