Infosec Island Latest Articles Adrift in Threats? Come Ashore! en hourly 1 Security Monitoring Planning Tool? Thu, 24 Apr 2014 14:42:01 -0500 The easy stuff is for wussies – how about I dedicate my time to creating a structured approach for deciding which monitoring technology to use under various circumstances? For example, a SIEM can be used to monitor a database for security issues using native database logs; or you can use a DAP tool. Similarly, firewall logs fed into a SIEM can sometimes work for monitoring anomalous network connections, in other circumstances a NIPS or even an NBA may be a better choice.

So here’s what I’m thinking about: can we build a decision tool that works like this:

Decide WHY = think attacks, privileged user activities, resource access [regulations define some of the WHYs for you, but won’t be explicitly mentioned here]

Pick WHAT = think databases, files, entire systems, connections, data in various forms, etc


Get the best 1-2 technology choices for each set of circumstances.

Realistic? Worth doing? What do you think?

P.S. This decision tool will intentionally avoid answering the “Why?” question for you (this is done elsewhere when risk related activities are undertaken) and also will focus on technology choices (leaving operational processes to be established separately).

This was cross-posted from the Gartner blog. 

Copyright 2010 Respective Author at Infosec Island]]>
The Enterprise Network: Effective Protection Strategies Thu, 24 Apr 2014 14:37:00 -0500 Enterprise networks are at risk. According to an interagency document prepared by the National Institute of Standards and Technology (NIST), “security vulnerabilities are rampant,” and the CERT division of Carnegie Mellon University reports approximately one hundred new vulnerabilities each week. How can companies protect their networks against existing and emerging threats?

Think Strategically

The first step is to think strategically, which means creating policies and procedures aimed at the enterprise network as a whole rather than handling issues case by case. Perhaps the best example of this strategic need comes from the cloud — as noted by Cisco's recent Global Impact IT Survey, approximately half of IT professionals asked said security data protection in the cloud was a “top challenge” in moving from on-premise stacks to distributed computing.

Why? Because cloud technology, along with trends like bring-your-own-device (BYOD) and the integration of social media resources, have democratized access; employees, IT professionals and C-suite executives exist on a level playing field when permissions aren't gated by a local IT department alone. As a result, companies require broad network protection strategies that work across resources, devices and platforms.

Define User Rights

Threats to enterprise networks come from two sources: Outside agents such as hackers and internal actors (employees). In most cases, internal misuse of network resources is accidental, not malicious, but can still lead to a data breach if sensitive information is sent to third parties or malware is accidently loaded onto company servers. To guard against employee missteps at all organizational levels, IT professionals need to implement a broad user rights strategy. This means restricting access to network resources based on both role and need, and ensuring the number of users with admin privileges is kept as low as possible. Defining user rights starts with an evaluation of job type: What does a user need to access based on their current workload? Next, IT admins must consider oversight. While C-suite members may need access to high-level use summaries or network uptime data, they don't necessarily require admin rights. A clear and concise user rights strategy helps eliminate unneeded access points.

Get Offensive

To deal with external network threats, enterprises need a security strategy focused on proactively preventing malicious actions rather than dealing with their aftermath. This is especially important for cloud environments where IT admins don't have direct control over the server hardware or connections. Before any external request for access or data is granted, the code it contains should undergo a behavioral analysis along with whitelist verification — if it fails either check, the recommended next step is to quarantine the code in a unique virtual environment where any file executions won't harm the network.

A combination of software-as-a-service (SaaS) based security tools and IT oversight is required to implement this security strategy approach. Based on real world experience it is well worth the time saved in proactive prevention rather than having to spend cycles and resources on remediation.

Continually Monitor

In addition to gating access permissions and identifying external threats, companies also need to monitor network use moment by moment, according to IT Business Edge. This allows IT professionals to identify mobile devices that don't comply with access policies and report instances of failed authentication. In addition, real-time monitoring gives an enterprise the ability to pinpoint resource drains on a network — these could be anything from a malfunctioning app to a bogged-down public server or even a poor network connection. The right tools let IT admins see their entire network at a glance, from the desktop computer one office over to the farthest reaches of a public cloud.

The enterprise network remains a popular target for hackers and fertile ground for employee missteps. To protect company data and resources, it's critical to develop a multi-faceted strategy that effectively addresses user access rights, constant external threats, and the need for continuous network and system monitoring.

Author Bio:

John Grady is the Senior Manager of Product Marketing at XO Communications, a leader in network and unified communications services for enterprises. In this role John launched the award winning 100G services for XO and is now responsible for the XO Connect and XO Compute products.

Copyright 2010 Respective Author at Infosec Island]]>
Verizon 2014 DBIR: Hide Your Servers and Call the Cops Wed, 23 Apr 2014 11:27:00 -0500 By: Dwayne Melancon

I’m still digesting the Verizon 2014 Data Breach Investigations Report (DBIR), which was just released last night, but a couple of things have jumped out at me already after a quick read. First, looking at the graph below on the left, it seems that servers are more popular than ever as attack targets. This is interesting, particularly when compared to the decline in User Device breaches.

Are we getting better at security BYOD, or have attackers just realized there is more of what they are after on a server?  I would guess “density of lucrative assets per device” factors into this trend. Regardless of the driver, I think this is a good reminder to focus on the assets that could most harm your business and making sure they are secure.

Know what you have, know how it’s vulnerable, configure it securely, and continuously monitor it to ensure it isn’t compromised and remains secure.


On the right, we see the trends in the methods through which breaches are discovered. A few things stand out on this data set:

  • Law Enforcement continues to get better at discovering breaches – that is good to see. I still think law enforcement has a PR problem, though – I was talking with a news reporter last week who was asking me why law enforcement isn’t doing anything about catching the criminals. I wish I’d had this graph with me then, so I could show him that law enforcement is actually leading the charge in detecting these breaches, at least as far as the ones that are included in the DBIR. [Note: Yes, I realize, there could be some bias in the sample, as many of these incidents came from law enforcement agencies... but this data is from cases worked by those agencies, regardless of how the initial discovery occurred.]
  • Third-party discovery (with or without Law Enforcement) continues to rise. That means most organizations find out they’ve been breach after being notified by someone outside their organization.  Part of this may be a side effect of all of the free credit monitoring accounts people have been given as a result of past breaches. What do you think?
  • Internal discovery of breaches is flat-lining, which tells me that the traditional efforts of catching our own breaches is still not working. That is a complex problem, but one we need to figure out how to solve on a broad scale. The bad guys will continue to win if we can’t improve the state of the art in incident detection within the enterprise, and a silver-bullet appliance is not enough – this is about composite capabilities comprised of technology, human skills, process, and different thought models than we’ve been using.

Stay tuned for more observations as I am able to digest more of this report. Would love to hear your thoughts, as well…

This was cross-posted from Tripwire's The State of Security blog.

Copyright 2010 Respective Author at Infosec Island]]>
2014 SecurityWeek Golf Classic to Take Place May 22 at Half Moon Bay Wed, 23 Apr 2014 07:42:33 -0500 SecurityWeek Golf Classic

SecurityWeek Invites You to Participate in The 2014 SecurityWeek Golf Classic!

Our first classic is being held on May 22, 2014 at the prestigious world-class Ocean Course at Half Moon Bay, located just 23 miles from San Francisco International Airport. Throughout the day, your organization will have the opportunity to have fun and interact with customers, employees, information security professionals and the SecurityWeek team!

Golf Classic Agenda

Contact SecurityWeek for Sponsorship Information and Player Registration


Kaspersky Lab

Perched on a bluff high above the roaring
 Pacific with sea views delivered at every hole, The Ocean Course is aptly
named and boasts some of the best final four finishing holes in golf.

Opened in 1997, and designed by renowned landscape architect Arthur Hills, the golf course in the traditional "links style” design delivers "firm and fast” fairways. The wispy native grasses accenting the tees and the plaintive wail of the bagpipers
who play at weekend sundown, join forces to
transport players and guests alike back to
the game’s origins in Scotland.

Banquet Dinner

Following an exciting day of golf, attendees will be treated to cocktails and Hors d'oeuvres followed by a banquet dinner at the course clubhouse. With panoramic views of both the scenic links and dramatic ocean bluffs, meals created by renowned chefs, and a full bar with regional and favorite micro-brewed beers and spirits, the SecurityWeek Golf Classic will be a first class event and a day to remember!

Charity Auction 
to Benefit Wounded Warrior Project

The SecurityWeek Golf Classic will host a Charity Action to benefit wounded service members through the Wounded Warrior Project. The Wounded Warrior Project’s mission is to honor, empower, and engage our warriors, nurture their minds and bodies, and encourage their economic empowerment. Warrior families are provided comfort, care and education to help support the recovery of their injured warrior. With your help we can fulfill a vision of fostering the most successful well-adjusted generation of wounded service members in our nation’s history.

Registration is Limited, Signup Today

For Player Registration and Sponsorship Opportunities Please Contact Us

Copyright 2010 Respective Author at Infosec Island]]>
6 Minutes That Can Change Your Security Start-up's Life Wed, 23 Apr 2014 06:22:48 -0500 On May 19th the Suits and Spooks Security Start-up Speed Lunch will give each founder of up to 20 cyber security start-ups an opportunity to spend 6 minutes with Dan Geer, the CISO of In-Q-Tel, 6 minutes with Christopher Michael, the Cybersecurity Deputy and Director of Security Engineering for BAE Systems, 6 minutes with Edward V. Marshall, a Vice President of Credit Suisse, 6 minutes with Phil Rosenberg, a Director of Deloitte Financial Services, and at least two VCs. And that's just as of today.   

We only have room for 10 more Security Start-ups and I expect to close our New York event by this Friday. We still can accept VCs and corporate executives, and we have limited opportunities for sponsors.  

The good news is that we are looking at holding similar events in San Francisco, San Antonio, and Washington DC this year so if you can't get in for New York, you'll have other opportunities in the coming months.   

If you're wondering if this format works or not, I can tell you from personal experience that it did for my start-up (Taia Global). I'm simply modeling and expanding the process that I used for myself in the Fall of 2013 (a private luncheon about Aerospace and Information Security R&D). I can't promise the same results obviously, but I firmly believe that if you have a product worth pitching, every one of these executives will be eager to hear about it.  

Here's how to apply for our New York event.   Contact me if you want to be informed about our San Francisco, San Antonio, and Washington DC events (please specify which one). 

Copyright 2010 Respective Author at Infosec Island]]>
NIST Abandons Cryptography Algorithm in Wake of NSA Backdoor Concerns Tue, 22 Apr 2014 15:47:10 -0500 The National Institute of Standards and Technology (NIST) has made the decision to abandon a controversial cryptographic algorithm used for random number generation in the wake of allegations that the National Security Agency may have weakened the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) for the benefit of their surveillance activities.

Based on concerns over the algorithm, NIST had recently commenced a public comment period on the embattled algorithm so that researchers could further examine the encryption standard and its overall reliability.

“We want to assure the IT cybersecurity community that the transparent, public process used to rigorously vet our standards is still in place. NIST would not deliberately weaken a cryptographic standard,” NIST officials stated previously. “If vulnerabilities are found in these or any other NIST standards, we will work with the cryptographic community to address them as quickly as possible.”

NIST has officially announced the decision to remove the cryptographic algorithm from its revised guidance on random number generators provided in the Recommendation for Random Number Generation Using Deterministic Random Bit Generators (NIST Special Publication 800-90A, Rev. 1).

“The revised document retains three of the four previously available options for generating pseudorandom bits needed to create secure cryptographic keys for encrypting data,” NIST stated. “It omits an algorithm known as Dual_EC_DRBG, or Dual Elliptic Curve Deterministic Random Bit Generator. NIST recommends that current users of Dual_EC_DRBG transition to one of the three remaining approved algorithms as quickly as possible.”

The organization made the decision after strong suspicion that the NSA “backdoored” the random bit generator by weakening the encryption process, leaving NIST is in the awkward position of having to announce that they could not endorse their own encryption standard anymore because “recent community commentary has called into question the trustworthiness of these default elliptic curve points.”

Last September, security firm RSA sent an advisory to their developer customers warning against use of a toolkit that employs an NIST encryption algorithm by default that is suspected to have been “backdoored” by the NSA, and in October secure global communications provider Silent Circle announced they would replace NIST cipher suites in their products.

“This doesn’t mean we think that AES is insecure, or SHA–2 is insecure, or even that P–384 is insecure. It doesn’t mean we think less of our friends at NIST, whom we have the utmost respect for; they are victims of the NSA’s perfidy, along with the rest of the free world. For us, the spell is broken. We’re just moving on. No kiss, no tears, no farewell souvenirs,” wrote Silent Circle co-founder John Callas of the decision.

Read More Here…

This was cross-posted from Tripwire's The State of Security blog.

Copyright 2010 Respective Author at Infosec Island]]>
Let’s Get Proactive with End User Security Tue, 22 Apr 2014 10:48:53 -0500 Where do most of the threats to the security of our IT systems lurk? The Internet, of course! Powerful malicious software apps are all over the Net, like website land mines, just waiting to explode into your computer if you touch them. And how about accessing social networks from your company work station? Do you really think that content on these sites is secured and only available to those you chose to see it? If so, then Im sorry to disillusion you.

So why do most concerns still let their employees casually access and surf the Web from their business systems? Especially in the present when most everyone has a smart phone or pad with them at all times? Businesses should embrace this situation and use it to their advantage. Why not set up an employee wireless network with all the appropriate security measures in place just for Internet access? (This network should be totally separate from business networks and not accessible by business computers). Its not expensive or difficult to administer and maintain a network like this, and employees could access websites to their hearts content (on their off time of course). And for those employees that are without a smart phone (an ever dwindling few), you could stand up a few kiosk computers that they could access using their employee wireless network password.

As for employees that need Internet access to perform their work duties, you should lock their access down tight. The best thing to do is to add needed websites to a white list and only allow those employees with a business need to access only those websites that are necessary and no others. Black listing and web filtering are partially effective, but they dont really work well enough. I cant tell you how often we have seen such filters in place at businesses that we assess that prevent access to gaming and porn sites, but still allow access to traps like known malicious websites in foreign countries! Go figure.

And dont forget to properly segment your business networks. Users should only be allowed access to those network resources that they need for business purposes. Users in workstation space should never be allowed to see” into server space. Preventing this will go a long way in curtailing attacks from the other big danger – the malicious insider. 

Thanks to John Davis for writing this post.

This was cross-posted from MSI's State of Security blog.

Copyright 2010 Respective Author at Infosec Island]]>
Verizon Publishes Vastly Expanded Data Breach Investigations Report (DBIR) Tue, 22 Apr 2014 05:16:36 -0500 Verizon expanded its 2014 Data Breach Investigations Report to include security incidents that didn't result in breaches and provided industry-by-industry analysis of various threat types.

Point-of-sale (PoS) attacks are declining, while Web application attacks and cyber-espionage is increasing, according to the latest edition of the annual Verizon Data Breach Investigations Report (DBIR).

In previous years, the highly regarded report from Verizon focused on actual data breaches investigated by either Verizon's security team or by one of its global partners. This year, the team decided to expand the report definition to include security incidents that didn't result in breaches in order to "gain a better understanding of the cybersecurity landscape," Marc Spitler, a senior risk analyst with Verizon's RISK team, told SecurityWeek.

Read the Full Story at SecurityWeek.Com

Copyright 2010 Respective Author at Infosec Island]]>
Interview with Chris Petersen, LogRhythm co-founder Tue, 22 Apr 2014 05:13:23 -0500 An Interview with LogRhythm's Chris Petersen

In March I began my quest to interview some of the most interesting folks in the Colorado security community. The goal of this series is to explore some different perspectives on security in the region, and have some fun doing it. The first installment was an interview with information lawyer Dave Navetta.

This time I had the pleasure of sitting down with Chris Petersen, CTO and co-founder of LogRhythm. For those unfamiliar with it, LogRhythm is an independent security intelligence company. They are one of the heavy hitters in the continuously growing security information and event management (SIEM) field. Any serious conversation about SIEM field will include them. All that, and they are based right in our back yard.

I chose to reach out to Chris Petersen to get the perspective of someone who started with just an idea and some development skills, and turned those into a market-leading security organization. Over the last few months, I’ve asked some local security folks what they’re interested in, one of the topics that kept coming back to me was, “How do I go from my good ideas to a product that generates value?” My hope is that Chris can shed some light on that question.

I worked through a contact I have at LogRhythm (thanks Jim!) to get in touch with Chris and set up a time to get together. On April 8th I made the trek to Boulder for the meeting at the LogRhythm headquarters. The facility is a fairly standard building from the outside, but inside it has all the trappings of a growing tech company. Way too many people crammed into too small a space, foosball, ping pong and free sodas were expected. The roll-up doors that make for a great BBQ setup were unique and very fun. Chris and I settled down in a conference room and spent about an hour chatting.

My questions are indicated in bold, with Chris’s responses paraphrased below.

Chris, to start us off, would you tell me your story? How did you end up starting LogRhythm?

After college I worked for PricewaterhouseCoopers (PwC) doing IT audit. While there, I came into contact with their security services practice; the teams that got to do interesting things like break into banks for ethical hacks. That practice piqued my interest, and I decided to move into that area.

It was at PwC that I started developing tools to help with these assessments. Specifically, I created tools to help with the security assessments, database audits and an early GRC tool (Governance, Risk Management and Compliance tool). The creation of that GRC tool got the attention of Ernst and Young, and they recruited me and my boss, and we went there to build out their national security practice. There I developed the software tools to help deliver their services, and was able to help build one of the first managed vulnerability services, which we offered to our customers.

A Qualys type tool?

Yes, similar. At Ernst and Young I really had the opportunity to hone and improve on my development skills.

Where did you learn to code? Were you trained in school?

No, I mostly just picked it up. I taught myself how to code in order to solve problems. From automating assessment tasks to creating that early GRC system, I created ways to do my job more efficiently.

While at Ernst and Young I built  a 10 person development team. After that I went to Counterpane, Bruce Schneier’s company. They were one of the first MSSP’s, located out in Silicon Valley. I moved out to San Jose to help Counterpane develop their MSSP backend, which was essentially a SIEM.

I had always wanted to be an entrepreneur, and after Counterpane I evaluated whether I was ready to do that yet. I decided that while I had successfully proven that I could develop meaningful products, I didn’t yet know how to take a product to market. So before I would start my own company, I wanted to get experience with things like pricing, packaging, marketing and selling a product. So I sought a position in product marketing.

I landed a position with Enterasys Networks as the Product Marketing Manager for their Dragon IDS product.

That was a pretty big job change, isn’t it?

Yes, absolutely. But it was very good. I have always looked at myself as the CEO of Chris Petersen Inc. I saw this as an opportunity to help round out my organization, and get those skills I needed in order to accomplish the goal of entrepreneurship.

I worked at Enterasys for a couple of years, getting the experience I needed, and felt that I was ready to start my own company. However, it wasn’t easy to make that jump to strike out on my own.

In 2001, about a year after I joined Enterasys ran into problems, specifically an SEC probe. Over the next 12 months we lost quite a few people and experienced multiple rounds of layoffs. It was a tough time. One morning on the way to work I prayed that God would give me the courage to move on and start my own company. That same day I got laid off.

Wow. Is that a sign or what?

So yeah, I guess I would take that as a sign. After that, I headed out to Colorado to clear my head a bit. While there at Steamboat, I met up with Phil Villella, who was working on his PhD in Physics. He was creating algorithms to help determine interesting things like whether a missile in a silo would go boom after sitting there for 20 years. So, he had a skill set to find interesting facts from massive amounts of data. That’s where our paths crossed. I shared some of my ideas for analyzing data from systems like firewalls and intrusion detection systems, and he brought his expertise in teasing out actionable data.

We ended up spending three weeks at my place in DC, determining whether there was a real product there in our ideas. We sat at my kitchen table creating prototypes, testing if we could use authentication data to identify a compromised account. We were trying to look at the data in a different way to eliminate false negatives (missing real security incidents). In the end we proved that we could do it. And we decided this concept had real value.

Then we had a decision to make. Is this a technology that we would license to other companies, like the ArcSights of the world? Or would this turn out to be its own company? What we realized is that even if we built the algorithms, nobody was really doing SIEM right. So to really achieve our vision, we needed to reinvent SIEM and do it right.

Once we decided that, we went all in. I sold my house, netting about $100,000, and we pooled our resources to live on for the next couple of years. We rented a house together so we could bootstrap the business and get a product to market. Rather than seeking out venture capital early on, we decided to put our time and focus into building a great product and finding some customers.

At about that same time, in early 2004, we decided to move back to Boulder, so we’d be living where we wanted to be in the long-term. Colorado was close to our families, and it is where I wanted to settle down and start my own family.

Through these years we were living as cheap as possible. We drinking a lot of Miller Lite, ate bone-in chicken thighs and beans and rice. We really kept all expenses as low as possible.

Miller Lite, huh?

We do like good beer, but it just wasn’t in the budget.

No sales at this point, right?

No, we were mostly just working on the product at this point. After about two years exclusively focused on development we knew we needed to focus on other aspects of the business. While Phil continued to focus solely on product development, I began working on other areas including creating marketing collateral, making cold calls. In this timeframe we attended our first trade show to drum up leads.

Is there where you got that first sale?

No. At about that same time a friend of mine was working at Wall Street On Demand in Boulder. He made an introduction to the IT team there that was looking into log management. In May of 2005 they became our first customer. That was good timing… they wrote us a check for $40,000 for a software license, and by then all of our money was gone. I had begun putting things on my personal credit cards. There was no more money in the bank and we were getting pretty nervous.

Shortly after getting our first and second sales, I met an executive through my USTA tennis team, Andy Grolnick. He was a blue chip. He had been supporting some entrepreneurial incubator programs and doing general consulting for start-ups. He had been the general manager for the Iomega Zip Drive. He was definitely someone who had “been there, done that.” That’s a hard thing to find in Boulder.

At the same time we saw the competitive landscape changing. There were new competitors emerging, and many of them were very well funded. They were going to market with a very similar story as ours, but they were doing it with a bigger team, and a lot more money. We decided that in order to compete we needed to bring in a CEO who could help us get funding and allow Phil and I to focus on product.

So we started to recruit Andy to LogRhythm. He took a deep look, and we were able to convince him to join us in September of 2005.

So now LogRhythm has employee number 3?

Yes exactly.

We were very careful about who we brought in to invest. All three of us were in violent agreement about what we wanted to make the company into it. We wanted to build a company where:

  • We and others would enjoy coming to work
  • Innovation is highly valued
  • Customer success and satisfaction is a focus
  • We could control our own destiny

Our focus on those goals from an early point was critical. It led us to put off getting funding longer than usual; get more customers before we took funds, which ultimately allowed us more flexibility to pick the right kind of investors. Those who shared our vision for the kind of company we wanted to build.

It sounds like there’s some advice for the would-be entrepreneur there.

Absolutely. Be very careful about who you bring in as an investor. Those people will be the ones sitting around the board table with you, deciding the future of your company. You want to be sure that they will be a good partner. Be careful who you do business with.

So, you took capital, what did you do with that money?

We used it to grow quickly, and it paid off. We had an annual growth rate [CAGR, for the financial types] greater than 100% from 2007 to 2011 and have continued to see accelerated growth well ahead of the rapidly growing security market.

As you look back on the LogRhythm story, what do you think were your biggest challenges?

The first big challenge was simply making that total commitment to doing this. With an effort like starting a company, you can’t stick one toe into the water. I had to be willing to invest all of my savings, with the full knowledge that I could very well lose all of it. And I had to be okay with that.

That said, those first years were also among the most fun. Bootstrapping and creating a product was great. But underlying all of that there was always uncertainty. Will this really work? Will the money hold out?

The second biggest challenge was the decision to give up some control of my company. This is one area where a lot of entrepreneurs fail. It’s hard to bring in someone else to be the CEO of the company you founded. However, it was clear for us that it was the right thing to do. If we hadn’t brought in someone else to been the CEO I could have strangled the vision of my company by holding on too tight.

Okay, changing topics on you. For those reading this looking to get into the security field, what are the skills that you’re always looking to hire?

Software engineering and architecture is always in demand.

General security professionals. Threat detection, security analytics, incident response, forensics, and intrusion detection.

Finally, in our labs area, we’re always looking for expects in malware research, APT research, and general cybercrime knowledge.

One last question for you. What is the biggest mistake you see CISOs and other security leaders making?

There is still too much of a bias toward preventative security controls. While prevention is important, we should be focusing much more on monitoring and incident response so that we are aware when prevention has failed and can respond to it. Unfortunately we operate in a world where it’s not “if” a company will be breached, but rather “when.”

Thanks so much to Chris for taking the time to share his experiences. It was really fun for me to get to hear the story of how he identified a need, found a great team, and eventually built one of Colorado’s best companies. I hope it was fun for you guys to get to ride along with me. If you have thoughts on other Colorado security individuals (or types of individuals) you’d like me to speak with, drop me a line and I’ll see what I can do. 

Cross-posted from Enterprise InfoSec Blog from Robb Reck. 

Read More Security Startup Inteviews at SecurityWeek

Copyright 2010 Respective Author at Infosec Island]]>
Detecting OpenSSL-Heartbleed with Nmap & Exploiting with Metasploit Mon, 21 Apr 2014 15:47:00 -0500 You can now quickly detect the OpenSSL-Heartbleed vulnerability very quickly on a network using the ever popular nmap command, and with the latest modules from Metasploit you can quickly see the exploit in action.

For this tutorial I will be using a WordPress server and Kali Linux running in two separate VMWare virtual machines.

For a vulnerable server, I used one of Turnkey Linux WordPress VMs.  There are security updates available for Turnkey’s WordPress, but during the VM setup, and for this tutorial, I purposefully told the VM NOT to install the security updates so I could test for the OpenSSL vulnerability.

Once the WordPress VM was configured (just answer a few simple questions) I then fired up my Kali Linux VM.

Nmap has created a Heartbleed script that does a great job of detecting vulnerable servers. The script may not be available in your version of Kali, so you may have to manually install it.

Detecting Exploit with Nmap

If the Open-Heartbleed script is not already included in your nmap install, you will need to manually install it.

This is pretty easy, just visit the OpenSSL-Heartbleed nmap Script page, copy and save the nmap nse script file to your nmap “scripts” directory as seen below:

Heartbleed nmap script save

You will also need the nmap “tls.lua” library file, save this to the nmap “nselib” directory as seen below:

Heartbleed nmap tls library

That is it, we can now use the heartbleed script in nmap to detect vulnerable systems.

To use the command the syntax is:

nmap -sV --script=ssl-heartbleed

All we need to plug in is the IP address of our target test WordPress site, in this instance:

heartbleed nmap script command

And if the target machine is vulnerable we will see this:



nmap heartbleed vulnerable detected


Risk Factor: High

Exploiting with Metasploit

Now that we know we have a vulnerable server, we can use the latest Metasploit OpenSSL-Heartbleed module to exploit it. (Note: you can use the module to detect vulnerable systems also)

Update metasploit to get the latest modules. Just type “msfupdate” at a Kali command prompt:



Now run “msfconsole” to start Metasploit and you will be presented with the Metasploit console:



Metasploit prompt


Next search for the heartbleed modules:


heartbleed search


Notice there are two, we will just be using the scanner.

Type, “use auxiliary/scanner/ssl/openssl_heartbleed“:

heartbleed metasploit module

We are just going to set two options, “set VERBOSE” to true and we need to “set RHOSTS” to our target IP address as seen below:



verbose rhosts

And finally, just “run” the exploit:

heartbleed leaked data

If you click on the picture above, you will see that Metasploit communicated with the server and was able to pull random data from the server’s memory.

The important thing to note here is that it pulls random data from memory. There is no guarantee that you will find account credentials, session cookie data or critical data every time you run this. But the danger is in the fact that it could display sensitive data.

Thus the best practice (if you haven’t already) is to check your systems for the heartbleed vulnerability and patch them immediately. After the systems are patched change any passwords on the effected machines.

As always, never run security scans or checks on systems that you do not own or have approval to scan.

If you enjoyed this tutorial and want to learn more about Kali Linux and Metasploit, check out my latest book on Amazon, “Basic Security Testing with Kali Linux“.

This was cross-posted from the Cyber Arms blog. 

Copyright 2010 Respective Author at Infosec Island]]>
Understanding What Constitutes Your Attack Surface Mon, 21 Apr 2014 08:40:10 -0500 By: Katherine Brocklehurst

In the first article in this series, we discussed a little about Understanding Attack Surface Analytics, and in this second installment we will examine exactly what constitutes your attack surface.

Put simply, your attack surface is the sum of your security risk exposure. Put another way, it is the aggregate of all known, unknown and potential vulnerabilities and controls across all software, hardware, firmware and networks. A smaller attack surface can help make your organization less exploitable, reducing risk.

A typical attack surface has complex interrelationships among three main areas of exposure: software attack sur­face, network attack surface and the often-overlooked human attack surface.

The Software Attack Surface

The software attack surface is com­prised of the software environment and its interfaces. These are the applications and tools available to authorized (and unauthorized) users.

The software attack surface is calcu­lated across a lot of different kinds of code, including applications, email services, configurations, compliance policy, databases, executables, DLLs, web pages, mobile apps and device OS, etc.

The Network Attack Surface

The network attack surface presents exposure related to ports, protocols, channels, devices (from routers and firewalls to laptops and smart phones), services, network applications (SaaS) and even firmware interfaces.

Depending on your infrastructure, you may need to include cloud servers, data, systems and processes to your network attack surface.

The Human Attack Surface

Humans have range of complex vulner­abilities that are frequently exploited. One of the great strengths of highly secure organizations is their emphasis on communicating security awareness and safety principles to their employees, partners, supply chain and even their customers (as when using the web to gain secure access to bank or 401K accounts).

Many breaches begin with an exploit directed at humans and it’s very clear that malicious intent, inadvertent errors and misplaced trust can all be exploited to cause great harm. Examples of successful attacks vary widely, (most notably phishing and spear phishing), but a comprehensive index should include processes, physical security, and privileges (including the ability to attach, read or write to removable devices).

In summary, to accurately determine your attack surface risk, all three of these attack surfaces must be considered. Using existing and emerging ASA technologies can pro­vide improved insight and visibility to your organization’s security posture in each of these areas, as well as provide the underlying basis for the score.

For more information, check out the whitepaper Understanding Your Attack Surface: The First Step in Risk-Based Security Intelligence, and feel free to contact me at

In the next article in this three article series, we will examine Effectively Communicating Attack Surface Analytics… Stay tuned!

This was cross-posted from Tripwire's The State of Security blog.

Copyright 2010 Respective Author at Infosec Island]]>
Mocana Calls Heartbleed a “Wake-Up Call” for Makers of Smart Connected Devices Mon, 21 Apr 2014 07:22:08 -0500 Properly Protecting the Internet of Things Will Require Changes from Business as Usual

Mocana today urged developers of smart connected devices – the smartphones, routers, switches, smart TVs, industrial controls, heating and ventilation systems, appliances and other commercial and consumer hardware increasingly attached to the Internet of Things (IoT) – to heed the wake-up call of Heartbleed and ensure their products are secure, private and safe. According to security experts at Mocana, the Internet of Things puts computers into all sorts of smart connected devices, especially for consumers, and most manufacturers are less accustomed to providing adequate security than most PC and software makers.

The problem, especially on the consumer side, goes to the heart of the way the market has developed up until now, according to Mocana. Millions of existing devices were manufactured using old versions of software, which cannot be easily upgraded or patched, if at all, when a problem like Heartbleed arises. The result, according to a recent blog post by computer security and privacy specialist Bruce Schneier, is that “hundreds of millions of devices have been sitting on the Internet, unpatched and insecure, for the last five to ten years.” And this problem will rapidly get worse if something doesn’t change, because it is still early days for the Internet of Things.

“Embedded systems developers need to start taking security more seriously and design their systems better. They need to start by using security software that’s proven and built expressly for embedded systems and then build their systems so that the software in these devices can be updated or patched, as needed,” said Paul Fulton, vice president of IoT products at Mocana. “Mocana offers a broad range of embedded security solutions for the Internet of Things, including our NanoSSL™ secured data transport technology, that do all the security ‘heavy lifting’ for device makers by providing security through easy-to-use APIs for rapid integration.”

NanoSSL is Mocana's super fast, super small SSL/TLS solution specifically designed to speed product development while providing best-in-class device security services for resource-constrained environments. NanoSSL is extensible, small footprint (50KB), platform-agnostic and includes an optional government-certified FIPS 140-2 level-1-validated crypto core. NanoSSL includes a full-featured key generator and certificate management client, and supports U.S. government Suite B crypto algorithms and the new RFC standard for TLS 1.2.

“Mocana NanoSSL isn’t just another SSL toolkit. It’s a professional device security platform that helps our customers shave months off their engineering timelines while delivering differentiated products with advanced security features that just aren’t available anywhere else,” said John Aisien, senior vice president of marketing and corporate development at Mocana.

“It seems that almost every day now we are learning of more places affected by Heartbleed, one of the latest being the Android 4.1.1 operating system, which is found in about a third of all Android devices,” said Fulton. “The industry is moving at full speed to build out the Internet of Things, yet we keep learning that devices we thought were secure aren’t. At some point, hopefully soon as a result of this wake-up call, manufacturers will start to take security more seriously and take the steps necessary before the inevitable happens again.”

According to Fulton, Mocana has noticed a trend of major OEMs looking to migrate away from open source security solutions to commercially produced products like Mocana NanoSSL as more vulnerabilities like Heartbleed are exposed in commonly used open-source security implementations. Mocana is addressing the needs of these customers with a convenient migration package to help simplify and speed the process.

Source: Mocana

Copyright 2010 Respective Author at Infosec Island]]>
Stop the Bleeding: How Enterprises Can Address the Heartbleed Bug Mon, 21 Apr 2014 07:19:00 -0500 By now, you’ve likely heard about the recently discovered Heartbleed bug. At its simplest, this bug allows cyber criminals to exploit a flaw in technology that encrypts sensitive information, making all types of communications sent over an “HTTPS” connection, including emails and online credit card payments, as easy for them to read as this sentence. But that’s not all – once that sensitive personal and/or company data is obtained, cyber criminals can then use the stolen online personas to gain access to other password-protected areas, such as online banking accounts, social media channels and corporate networks. Security expert Bruce Schneier said that “on the scale of 1 to 10, this is an 11.” Understandably, there’s a lot of media attention being given to this topic. But before hitting the panic button, read on to see how exactly your enterprise, or even you personally, might be affected.  

What’s the Heartbleed bug again?

Secure sockets layer (SSL) and transport layer security (TLS) are widely used protocols that secure a wide range of communications across the Internet, from IMs to remote access, and Heartbleed is a vulnerability specific to an open-source implementation of these protocols aptly called OpenSSL. The bug gets its name from the nature of its attack, which involves piggybacking on an OpenSSL feature known as heartbeat. By exploiting this susceptibility, cyber criminals can compromise users’ cryptographic SSL keys, making what should be encrypted communications appear in plain text.

Why it’s a problem

According to Neil Rubenking of PC Mag’s SecurityWatch, the website “that was created to report on Heartbleed states the combined market share of the two biggest open source Web servers using OpenSSL is more than 66 percent.” And, as Douglas Crawford of Best VPN notes, “[Heartbleed] particularly affects websites that are powered by the Apache web server, but as this is over 50 percent of all websites on the Internet, this is of little comfort.” The threat to the average end user is apparent – cyber criminals exploiting this encryption flaw can easily intercept credit card information and other types of sensitive personal data. But enterprises are at risk, too, especially given the large number of organizations that have coped with BYOD by implementing SSL VPNs.

How to address the issue

We often discuss how the mobile security industry as a whole tends to be more reactive than proactive when it comes to identifying and mitigating threats. However, in a strange twist of irony, older versions of SSL are immune to Heartbleed. But that doesn’t mean that you shouldn’t take action. Rather, it’s a good idea to leverage ephemeral keys (a cryptographic key that is generated for each execution of a key establishment process) to further solidify an enterprises defense against the bug. If you are operating with a VPN that uses the compromised OpenSSL, ZDNet’s Steven J. Vaughn-Nichols hits the nail on the head – you need to revoke your old SSL digital certificate from your certificate authority (CA) and get a new one. If you don’t, “It would be like you replaced your old lock with a brand new one… that takes the same old key.”

Once the certificate has been renewed, the next step is to contact your VPN provider to find out how they’re handling the situation. If your VPN has central management capabilities, compromised certificates can be automatically revoked and replaced with new ones for all users by network administrators. A centrally managed VPN that can interoperate with other network and security technologies is a crucial component of a broader defense in depth strategy. If a user is compromised, technologies such as dynamic personal firewalls, a robust anti-virus solution, anti-malware software, etc. can work together to mitigate further risk and keep other users and the network safe. Despite its effectiveness, unfortunately it often takes a major revelation such as the Heartbleed bug to help enterprises recognize the importance of shoring up their network security.

If your provider is not hurrying to patch the hole in their OpenSSL implementation and/or taking steps to better implement a defense in depth framework, you may be justified in hitting the panic button. In these instances, it’s imperative to make your customers aware of the threat and what you’ve done to address it, in addition to outlining the proactive steps they can take to protect themselves. 

This post originally appeared on VPN Haus

Related: Why The Heartbleed Vulnerability Matters and What To Do About It

Additional Resources:

• Is Your Enterprise Managing Certificates? Three Reasons It Should Be

• Forrester Attacks On Trust Report

Copyright 2010 Respective Author at Infosec Island]]>
An Open Letter to Executives Thu, 17 Apr 2014 10:38:29 -0500 I apologize for not posting anything recently, but I have been busy dealing with my taxes, QSA re-certification and clients.  Over the years that has involved dealing with people that I would like to think know better.  But based on my interactions with them, it is painfully obvious that they do not.  As a result, I have decided to write this letter to all of you in hopes that you get a clue as to how your short sidedness is going to ultimately sell your organization “down the river”.  I should have published this letter a long time ago as this is not a new issue.


 Dear Executive:

As I sat in the meeting, I watched your body language as I delivered our report on how well your organization is secured.  Based on my observations, it is painfully obvious that you do not have a clue as to the importance of security as well as you really do not care.  Since I want my bill paid, I was polite and did not take you to task as you should be taken.

So, let me put this into blunt language that you might better understand.

First and foremost, as an executive of the organization, you have a fiduciary responsibility to protect the assets of the organization.  Based on our findings, you are not protecting those assets, you are not even close.  I realize that all of this technology baffles you, but it is that technology where your organization’s life blood of intellectual property resides in orders, formulas, blueprints, specifications, customer lists and other key or sensitive information.  Without that intellectual property, your organization does not exist.  Yet as we went through all of our findings, you argued time and again about what it will take in time, money and/or manpower to appropriately secure your organization.  While I appreciate your concerns, this is what it takes to secure an organization that relies heavily on technology.

Second, security is not perfect.  I am not exactly sure where you got the impression that security is perfect, but that is wrong and you need to adjust your thinking.  Security is all about managing and minimizing risks.  As an executive, that is one of your primary job functions.  Yet your three/five/seven/ten year old risk assessment seems to point to the fact that risks and managing those risks are not a priority.  As if that was not enough, we pointed out a number of areas where risk exists but there is no evidence that the management of those risks was being done.  The recommendations we provided you offered a number of viable solutions, however they will all require changes to the organization, which seemed to be your biggest reason as to why our recommendations could not be implemented.

Third, doing the bare minimum is not going to secure your organization.  While we were talking about the PCI DSS, any security framework is merely the ante into the security game.  If you truly want to be secure it will take significant time and a certain amount of money to make that happen.  Buying security appliances and other “widgets” can only do so much.  One of the biggest findings in our report is that your existing tools in use are not being used properly and warnings and alerts are being written off as “false positives” without any investigation.  With the level of sophistication of attacks rising exponentially, based on our assessment. those tools are doing very little to protect your organization.  Another area of great concern is that your employees are, for the most part, unable to recognize current scams and threats.  As you correctly pointed out, security awareness training is not going to stop every attack, but what you missed is that such training should significantly reduce such attacks’ effectiveness.

Fourth, you need to read the definition of “compliance”.  As defined in Merriam-Webster’s dictionary, compliance means, “conformity in fulfilling official requirements”.  As our findings pointed out, you are not in compliance with a number of key “official requirements” defined by the PCI DSS.  Without adequate “official requirements” such as policies, standards and procedures, how do your employees know their responsibilities and what you are holding them accountable?  Based on our discussion of findings, you apparently are of the opinion that your employees should just intuitively know their responsibilities and accountabilities.  “Intuitively obvious” may apply to the operation of an Apple iPod as stated by Steve Jobs at its introduction, but that phrase does not apply the running of an organization.

Finally, a compliance program is not all about checking a box.  I know most auditors/assessors seems to operate that way and most executives want it to work that way, but a proper compliance program should never, ever work that way.  Compliance means looking at all of the organization’s protective, detective and corrective controls (the control triad) and determining if they are: (1) functioning properly, (2) designed properly, (3) minimizing the risks and (4) in need of any new controls or changes/enhancements to existing controls to make them function more accurately or efficiently.  While you agreed with our findings regarding the control issues we identified, your argumentative behavior about them seems to indicate otherwise.

I wish you and your organization the best of luck because it seems that your idea of risk management is to rely on luck.  I would like to tell you that you will succeed with that approach, however the statistics say otherwise.


Your Frustrated Assessor

This was cross-posted from the PCI Guru blog. 

Copyright 2010 Respective Author at Infosec Island]]>
FAQs Concerning the Legal Implications of the Heartbleed Vulnerability Wed, 16 Apr 2014 15:01:37 -0500 Contributors to this post include:  Scott KollerDavid NavettaMark Paulding and Boris Segalis)

By now, most of the world is aware of the massive security vulnerability known as Heartbleed (it even comes with a slick logo and its own website  created by the organization that discovered the vulnerability).  According toreports this vulnerability has been present for two years with respect to approximately two-thirds of the servers on the Internet (those that utilizeOpenSSL version numbers 1.0.1 through 1.0.1f and 1.0.2-beta1).  Mashable is keeping a list of some prominent affected sites, including a status on their remediation efforts.  As discussed further below, this vulnerability, if exploited, could lead to the compromise of authentication credentials (e.g. usernames, passwords, encryption keys), and in some cases the unauthorized access or acquisition of information contained in communications sent over the Internet from, or stored on, compromised sites.

In short, the security of millions of organizations is likely affected by Heartbleed in three ways:

  • Communications to the Organization’s Servers.  The communications to and from the systems of organizations that utilize certain versions of OpenSSL may be at risk of interception.
  • Communications by an Organization’s Employees to Third Party Organizations Affected by Heartbleed.  The authentication credentials of personnel and information sent by an organization’s employees to business-related websites subject to Heartbleed (e.g. Dropbox) may be at risk.  If an employee logged into such a site his or her password could have been compromised, and hackers could also have obtained access to information sent by the employees over encrypted SSL channels and information on the business site itself.
  • Communications by Employees to Organizations Affected by Heartbleed During their Personal Use of the Internet.  An employee visiting a website affected by Heartbleed (e.g. Google and thousands of other common consumer sites) during their personal Internet use (at the home, office or offsite) could have had his or her username and password compromised.  If that employee uses the same username and password to log into his employer’s systems, those systems could also be at risk.

In addition to the serious security concerns implicated by Heartbleed, there may be legal consequences associated with this vulnerability, especially with respect to the potential unauthorized access or acquisition of personal information.  At this juncture it is imperative that affected organizations remediate the Heartbleed vulnerability, communicate with their customers, employees and other system users, and consider potential legal risks and obligations associated with Heartbleed.

In this blogpost we present some key FAQs concerning the security and resulting legal implications of Heartbleed.  Specifically, we address remediation efforts necessary to reduce security and legal risk associated with Heartbleed, password reset and communications to affected individuals, the applicability of breach notification laws, and potential investigation obligations under HIPAA’s Security Rule.


What type of information may have been exposed?  Does this breach expose “personal information” under breach notification laws?

The Heartbleed vulnerability does not target a specific file or type of information. Instead, the information exposed is whatever was in the computer’s active memory (not hard drive storage space) at the time of the attack. For every request made by the attacker, the Heartbleed-vulnerable computer will respond with the contents of up to 64KB of memory. Because of this limitation the primary targets of an attacker exploiting Heartbleed are not files or documents. Instead, the real targets of this attack are usernames, passwords, and encryption keys because they are regularly stored in active memory, small enough to fit within 64KB of data, and can be leveraged to access even more information.

Under California’s breach notice law, “personal information” is defined to include the following:

 A user name or email address, in combination with a password or security question and answer that would permit access to an online account.

As such, the exploitation of Heartbleed that captures this information could trigger breach notification in California. Moreover, if authentication credentials compromised as a result of Heartbleed are further leveraged, highly sensitive information on an organization’s systems or affected third party systems may be at risk, including trade secrets, intellectual property and personal information (essentially anything accessible using the authentication credentials at issue).  Therefore, if Heartbleed is exploited, organizations that regularly transmit or receive personal information may be at risk, and may have to notify affected individuals.

Is an attack using the Heartbleed vulnerability detectable?

Now that security professionals know what to look for, it is possible to detect and prevent an attack that uses the Heartbleed vulnerability. However, it is substantially more difficult to determine if an attack occurred in the past (and the vulnerability has been around for 2 years).

A Heartbleed attack leaves no trace on the target computer and signs of an attack are normally not logged. It is possible to detect if you previously captured all incoming SSL traffic or maintained very detailed server logs on TLS/SSL “handshakes.” However, most sites do not record their SSL traffic because the volume of information can be prohibitively expensive to maintain. Even those sites that record their SSL traffic or maintain detailed server logs, only do so for a short period of time due to the amount of data generated.  As a result, most organizations will be able to confirm the presence of the Heartbleed vulnerability, but unable to determine if it was actually used.

What should be done in response to the Heartbleed vulnerability?

At this point, Heartbleed is a commonly known vulnerability (whether that was true or not prior to its recent discovery is unclear).  Hackers, fraudsters and other nefarious forces, if they were not already doing it, are likely to launch attacks.  The longer an organization goes without remediating the vulnerability the greater the likelihood of a security breach and resulting legal liability and risk.  Organizations should move swiftly to address Heartbleed and reduce their risk, and should consider the following actions:  

  • Identify Vulnerable Systems (if any). The first step is to assess whether you have any vulnerable systems. Typical desktop or laptop computers are not affected by this exploit. The Heartbleed vulnerability is present on computers running OpenSSL version numbers 1.0.1 through 1.0.1f and 1.0.2-beta1. It also affects certain network hardware such as routers, switches, and firewalls. Be sure to check with the manufacturer to see if you have any vulnerable networking equipment or check the list maintained by Mashable by clicking here.  Notably, many organizations (about one-third of Internet sites) do not use Open SSL.  While they may not need to take action to directly address the vulnerability, they may still be at risk (as described further below).
  • Test Servers for the Heartbleed Vulnerability (time and resource permitting).  Next, the most common response is to immediately patch your servers.  However, if you have the time and resources available, you should test your servers for the vulnerability in the pre-patched state. Not every implementation of OpenSSL is susceptible and the ability to confirm if your systems were vulnerable in the first place will be extremely valuable.
  • Patch Affected Servers.  Upgrade to the latest version of OpenSSL and install the latest patch or firmware on all affected computers and hardware.   OpenSSL has made the patch available here (the upgrade with the patch is OpenSSL 1.0.1g.).   After you have patched or upgraded the affected equipment, be sure to restart and re-test the equipment to ensure the vulnerability is closed.
  • Revoke and Regenerate Existing SSL Certificates and Encryption Keys. Do not regenerate these certificates until after you have upgraded to the latest version of OpenSSL or you will jeopardize the security of the new certificate all over again.
  • Password Reset.  Finally, you will need to decide whether to notify individuals to reset their passwords (e.g. employees and customers) or reset their passwords yourself. Here, the results of your pre-patch testing will come into play and should help you make an informed decision. The key is to take a close look at the computers that were affected and the potential information that was exposed. A corporate mail server will store substantially different information that an online marketplace. The type of information accessible by the affected computer should help guide your decision. Even if your systems were not affected, your customers and employees may expect a response given the wide-spread publicity surrounding this exploit.

Our systems were not affected by the Heartbleed vulnerability.  Do I need to do anything?

Unfortunately, because of the widespread nature of this vulnerability, even organizations unaffected by this exploit should consider taking steps to address potential security risk arising out of Heartbleed.

If any organization’s employees has dealings with a third party organization with the Heartbleed vulnerability, the employee’s credentials used to log into the third party’s systems may have been compromised.  If that third party service stores sensitive information or personal information related to the organization it could be at risk.  Moreover, if the organization’s employee uses the same password on the third party site to log into the organization’s system, the organization’s system and information could be at risk.

Even personal Internet use (at home, at work or otherwise) could expose an organization’s systems and information.  Again, if an employee uses the same log in credentials for his or her personal Internet use,  then the capture of those credentials could allow access to the organization’s systems and information.

Even if the organization was not directly vulnerable to Heartbleed, it should consider requiring its employees to reset their authorization credentials.  In addition, organizations should direct their employees to not use the same password at work that they do for their personal sites and use (regardless of Heartbleed, this is a good idea anyway).

When should I tell my employees, customers and others to change their passwords?

Individuals should not change their passwords until after the relevant Heartbleed-affected site has been patched.  If an individual changes his or her password before the Open SSL patch is operational then the new password will be at risk of compromise.  Since so many websites and servers have been impacted by Heartbleed, this timing issue poses challenges.  For affected third party sites, one must attempt to ascertain whether the site has implemented the patch.  Some organizations are attempting to track the date when some higher profile websites have implemented the OpenSSL patch.

What should I tell my employees, customers and others about resetting their passwords?

To cover all the scenarios outlined above, you should consider communicating the following to your employees, customers and other affected individuals:

  • Reset Password to Organization’s Systems.  After the organization has implemented the OpenSSL patch it should tell its affected employees and customers to change their passwords (or force a password reset of such systems).
  • Reset Passwords to Third Party Affected Systems used by the Organization.  To the extent employees accessed Heartbleed-affected third party sites used by the organization, you should ask your employees to change their passwords to those systems.  You may also have to inform your employees concerning the timing issues discussed above – they should be told to change passwords only after the affected third party site has implemented the OpenSSL patch.
  • Employees that Use the Same Password for Work and Personal Use Should Change their Passwords.  Even if the organization’s own system was not affected by Heartbleed, and even if the organization does not utilize third party sites affected by Heartbleed, companies should consider asking employees and customers to change their organizational password if they use the same password for personal reasons.

Does the Heartbleed vulnerability trigger U.S. breach notification laws?

Breach notification laws define “security breach” in different ways.  For example, under California’s breach notice law, a “breach of the security of the system” is defined as:

unauthorized acquisition of computerized data that compromises the security, confidentiality, or integrity of personal information maintained by the person or business.

Other states also define a security breach in terms of “unauthorized access” (as opposed to acquisition), including Connecticut’s law which defines “breach of security” as:

unauthorized access to or unauthorized acquisition of electronic files, media, databases or computerized data containing personal information when access to the personal information has not been secured by encryption or by any other method or technology that renders the personal information unreadable or unusable.

Finally, under HIPAA HITECH, “breach” is defined as:

the acquisition, access, use, or disclosure of protected health information in a manner not permitted under subpart E of this part [the HIPAA Privacy Rule] which compromises the security or privacy of the protected health information.

45 CFR §164.402.  Based on the foregoing, standing alone, the fact that an organization was vulnerable to the Heartbleed exploit does not trigger U.S. breach notification laws.  However, if an entity discovers evidence that Heartbleed was exploited in a manner leading to unauthorized access or acquisition of “personal information,” notification may be required under State or Federal breach notification laws.

Does the HIPAA Security Rule Require Investigations to Determine Whether the Heartbleed Vulnerability Was Exploited?

As noted above, the Heartbleed vulnerability does not, in and of itself, constitute unauthorized access or acquisition of personal information subject to most state and federal data breach notification requirements, including the HIPAA Data Breach Notification Rule.  However, the HIPAA Security Rule contains a number of provisions that require covered entities and business associates to maintain procedures to monitor system activity for potential security incidents and investigate any such potential security incidents.

The HIPAA Security Rule requires covered entities and business associates to “regularly review records of information system activity, such as audit logs, access records, and security incident tracking reports.”  45 C.F.R. § 164.306(a)(1)(ii)(D).  HHS guidance materials further state that this specification “should also promote continual awareness of any information system activity that could suggest a security incident.”  CMS, HIPAA Security Series Vol. 2 Security Standards:  Administrative Safeguards, p. 7 (March 2007),available here.

HHS has not opined on any obligation to review historical system activity records to detect past attempts to exploit the newly discovered vulnerabilities.  Nonetheless, based on the Security Rule and associated guidance, covered entities and business associates should consider whether it is appropriate to review the available historical web server logs to identify attempts (if any) to exploit the Heartbleed vulnerability.

Nevertheless, such reviews may only be necessary if the covered entity or business associate has maintained the types of web server logs that are likely to record indicators of Heartbleed exploitation (discussed in greater detail in the FAQs above).  The HIPAA Security Rule requires covered entities and business associates to create and maintain appropriate records of system activity.  See 45 C.F.R. 164.312(b).  However, covered entities and business associates have significant discretion to create and maintain activity records based upon the formal assessment of their security risks.  Given the volume and historical insignificance of the relevant log data and widespread trust of OpenSSL among technologists, it would have been reasonable for covered entities and business associates not to retain persistently web server log data regarding communications “handshakes.”


Overall, in most cases, the Heartbleed vulnerability and associated security and legal risk is manageable as long as organizations take swift action to remediate their risk. That said, it is possible that some organizations have been subject to Heartbleed attacks, and more likely that hackers and other criminal elements will seek to exploit Heartbleed going forward. InfoLawGroup is currently answering questions for its clients and helping with communication strategy and management of this situation, and we are available to answer additional questions and provide support as needed.

This was cross-posted from the Information Law Group blog.

Copyright 2010 Respective Author at Infosec Island]]>
Security Pros Need Better Security Awareness Training Options Wed, 16 Apr 2014 11:59:36 -0500 By: David Meltzer 

One of the basic security measures that every company should be taking is giving security awareness training to its employees. This is part of Critical Security Control 9. CSC 9-3 says:

“Implement an online security awareness program that (1) focuses only on the methods commonly used in intrusions that can be blocked through individual action, (2) is delivered in short online modules convenient for employees (3) is updated frequently (at least annually) to represent the latest attack techniques, (4) is mandated for completion by all employees at least annually, and (5) is reliably monitored for employee completion.”

So I wasn’t the least bit surprised a few years ago when my team of security researchers was asked to take security awareness training. But, it did seem funny that this group, the most security aware people I know, were taking the same training as the HR team.

Not that I think they minded that much, as the online training quickly became a game of how could you hack the online training to give you a passing score without having to sit through an hour of videos (hint: although you may not be able to comprehend 15 videos playing simultaneously on your screen, it does substantially reduce how long it takes to watch 15 videos).

This does seem to be a common issue, though, and so I think it is valuable to give some options to the security pros in your organization. There is an opportunity to turn what is for them an annoying waste of an hour into something productive and valuable to the business. Here are a few ideas for implementing this control:

Give an “Advanced Option” as Part of Awareness Training

Anyone that really knows their stuff with security would probably opt to learn something useful instead of rehash what they already know. I recently made a technical report about how large organizations implement vulnerability management mandatory reading for one of my teams.

That probably took about as much time to read as an online awareness training class would take, but for this group I’d say it is far more valuable to educate them on one particularly relevant area of security, rather than cover the basics again. An advanced option could come from the same training system as your basic class, or it could be as simple as an instruction to watch a webinar or read a new report on an area of security.

Offer a Security Project in Lieu of training

For the security pros, your organization will probably get more out of them if they do something for security instead taking a class. We do brown bag trainings at our office, so if someone is willing to spend an hour teaching others about an area of security they are an expert at, why not let that fulfill their awareness duty for the year?

Or how about an assignment to design some posters reminding people of key security basics and put them up? If a security pro is willing to spend the time to do something to increase awareness for the organization, let them do it!

Turn Security Awareness into Continuing Security Education

The 20 CSC suggest reiterating training with updates annually, but many organizations have a tendency to repeat the exact same regimen every year. What about creating a program in your organization that encourages and offers continuing education around security for your employees, instead of simply repeating the same training options?

Those with professional certifications in security, like a CISSP, know that Continuing Professional Education credits are required to stay certified. That does not mean they need to go back over the original certification materials.

Whether you have the budget to offer external training opportunities to employees, or spend time creating a simple internal system of training credits, giving security pros the option to be exempt from awareness training as long as they have completed some security education in the previous time period makes sense.

Some small tweaks like this can make your security pros a little more appreciative of their company’s own policies, while benefiting the company at the same time – a cheap win-win.

So the next time that reminder goes out to your employees that they need to complete the annual security awareness training, spend a few minutes thinking about how you can make your pros happy while keeping them educated instead.

This was cross-posted from Tripwire's The State of Security blog.

Copyright 2010 Respective Author at Infosec Island]]>