So, if you watch any of the vulnerability lists that are out there, you may have noticed a recent spike in vulnerabilities that have been identified in various VoIP implementations from various vendors. If you’re not sure what I’m talking about, you might think about heading on over to http://www.microsolved.com and downloading our free threat intelligence tool, Watchdog.

If you’re already a Watchdog user, you may have noticed that MSI decided to go from green to yellow earlier this week. That decision was based upon the release of several vulnerabilities that have been identified in Cisco’s implementation of various VoIP protocols (oh yeah, and it’s patch Tuesday). Those issues ranged in vulnerabilities that could allow remote code execution to denial of service. We’ve also seen several problems arise in Avaya’s implementation of VoIP protocols over the past couple of months as well.

MSI has been saying that VoIP vulnerabilities were going to start popping up, for some time now. If I remember correctly, we started addressing this in our State of the Threat presentations about a year and a half ago. Over that time we’ve seen significant progress in the tools that have been developed to assist in managing VoIP deployments. While those tools have helped a lot of companies with their VoIP implementations, we’ve also seen them introduce unintended risks into their environments. We’ve also seen many more much more nefarious tools that are allowing attackers to gain access to the VoIP system. And if you consider how useful fuzzing has become at identifying unknown problems in network traffic and applications, the sky is the limit when trying to determine where VoIP vulnerability research is going to end up. That is why MSI is ecstatic to have been approached by several different entities to perform VoIP Risk Assessments on their VoIP systems.

While a VoIP specific Risk Assessment may be a fairly new thing, the premise is not. It’s simply a way of applying a proven methodology to assess whether the new (or old) VoIP system hasn’t introduced unknown risks into the environment. The methodology that we use is very similar to our normal Risk Assessment of an Information Security Program, though there are some minor steps that had to be added and tweaked. The primary goal of these responsible organizations is to ensure that they are performing their due diligence by having a third party assess their VoIP implementations, and we applaud them for their initiative.

So, we now know that “hackers” have been doing a ton of vulnerability research on the new iPhone since it was released. That research has turned up a couple of interesting vulnerabilities. The first is a flaw in the Safari web browser that could allow an attacker to take complete control over the phone by tricking the phone’s owner into following a link to a malicious website that would exploit a buffer overflow in the browser. The attacker could then listen to the room’s audio or steal SMS logs, the address book, email passwords, and much more. The other interesting issue that was found is the possibility of crashing the phone by doing some bluetooth fuzzing against it.

None of the revelations are new to security professionals or penetration testers. This is all just normal, run of the mill stuff that we see and deal with every day. What’s interesting to us is how quickly these issues were found and what it could mean, in the grand scheme of things. I’m not really interested in what will become of the iPhone. Mostly because I don’t have any plans on paying $600 for a phone. What does interest me is the consideration of how this is just one more piece of the “perfect storm” that mobile technology is going to bring to our lives.

For several months, maybe even a couple of years, MSI has been telling our clients and our friends how we believe mobile technology is going to lead to major problems for companies and individuals, alike. We all love the convenience that our newly acquired mobile devices provide. In some countries (look for it to make its way here soon) it’s not even necessary to carry plastic or cash anymore. Take for example, in some parts of Europe and Asia, its now possible to pay for your McDonald’s, or your soda from a vending machine, or buy your clothes at the retail store with a bluetooth enabled phone and a PayPal account. How about using that same bluetooth enabled phone and PayPal account that can be used to associate with the nearest pay day loan boutique, while you sit in the bar, for a quick loan to continue your happy hour. Or consider that certain cell phone companies are now making it possible to pay all your bills from your cell phone. Not to mention the accepted risk of laptops coming in and out of an enterprise. Or how about unnoticed wireless access points in your enterprise?

What many people don’t understand is what attackers are already doing to take advantage of the lack of security of these convenient technologies. People were going gaga over the iPhone before it came out. People in this country will LOVE the idea of being able to pay for things with their cell phone. What the consumer won’t be told is that there are already attackers setting up fake bluetooth ID’s for your phone to associate with. Imagine that Coke machine that has a bluetooth ID of “Coke”. Now imagine my laptop that is sitting on top of the Coke machine with a bluetooth ID of “CokeMachine”. How are you going to know which one to associate with? Will your phone even give you the option of choosing? What if it chooses the first one it sees. Ok, so I get your 75 cents and you don’t get the coke. What I also get is your PayPal account information. This is just one of the many examples that we could give.

The point of this post is not to discuss stealing 75 cents from a thirsty consumer. What we are concerned about is how the lack of security in these devices is being completely ignored because of the convenience they bring to the consumer. There will always be people out there that try to take advantage of the unsuspecting consumer. Occasionally, they will be successful. A little bit of education could go a long way towards teaching these same consumers how to remain vigilant and protect their identity, as well as their bank accounts. At the same time, the same educational programs need to be put into place in the corporate enterprise to ensure that these insecure mobile devices are not being brought into the enterprise, increasing the risk of compromise. We’d like to see much more information being distributed to consumers about the technologies they are using and how they could be inadvertently endangering their financial future.

On my way in to work this morning I heard a fairly disturbing news report about criminals using basic social engineering techniques to get family members of US military members, that are deployed to Iraq and Afghanistan, to divulge the servicemen and women’s personal information. Here’s how the attack played out:

Criminal obtains a list of members of a specific unit or command and tracks down the phone numbers of family members of those soldiers. Criminal then calls the family member and states that they are calling from the Red Cross and that their son/daughter/spouse has been injured in the course of performing their duties.  Then the criminal states that in order for the Red Cross to be able to transport the service member to a military hospital in Germany, the Red Cross needs to verify the Social Security Number and date of birth of the injured soldier. While the family member is upset, they quickly give out the information to ensure that their loved one gets the medical attention they need. At this point, the criminal now has all the information they need to begin the identity theft that we hear so much about.

This type of attack, while completely abhorent, has worked numerous times.  I have not been able to find any conclusive data that speaks to how many people have been affected, nor do I think it is important for the purposes of this blog.  What is important though, is to consider a couple of things.

1.) The Red Cross would never contact a military member’s family directly, without going through military channels.

2.) The Red Cross or military would never need to verify that type of information in order to proceed with medical attention.

3.) No person should ever give out that type of information over the phone, especially if you did not initiate the call

What really interests me though, is the creativeness of the attack.  It plays on emotion to be successful. Whether you are for the war or against doesn’t matter, everyone should be able to agree that it is an emotional subject, especially when talking about a loved one.  The lesson to learn from this is simple. Guard your personal identity very closely. This example only strengthens the notion that criminals will do very nasty things to get access to your information. This is a business to them…a very profitable business at that.

We know that the average consumer will always choose the metaphorical “Dancing Bear” when confronted with these types of attacks. At MSI, we have refined our services to include rigorous social engineering exercises for our clients.  While we have seen improvement in the security posture of our client’s user base (at least the one’s who have taken advantage of the service offerings), there is a part of me that believes that those users aren’t taking the knowledge we are giving them and applying it to their personal lives.  For the one’s that are, we commend you and hope you continue to interact with the masses in a secure way.  We would love to not hear any more of these types of stories.  Unfortunately, we truely believe that this current trend of identity theft is only going to continue.  At least until “average Joe” begins to understand the threat.

I received an email the other day from a buddy from my former life in the Marine Corps. The email was basically a mass spam letting all of his friends know that he was planning on having a party in the coming months and had created a website with a forum to track reservations and random conversation. Since it’s an 8 hour drive back out there to Virginia, I only get to visit a couple of times a year and this party sounded like a pretty good excuse to make the trip. So, I went ahead and registered for an account on the website and logged in to make my reservation and see what everyone had to say about the party and what they’ve been up to.

As soon as I logged in, I made my way to the forum links to join the conversations. When I clicked on the very first link, can you guess what I was offered? That’s right, a very juicy error message letting me know that an error had occurred in the application. Now, it’s great that the server informed me that an error had occurred, but i was astonished at all of the information it was giving me…just a normal user. The first thing that I noticed is that the error page showed the average user the complete, full path to the location of the script that had failed. Not only did it give me the full path, it also showed me the exact number of the line in the script that was causing the problem…in addition to 3 lines above and below the faulty line. In those lines I got to see several interesting SQL arguments being passed, complete with tables and fields and object names. If I were specifically attacking this site, this error message would have given me some great information. Since I wasn’t attacking the site, I promptly emailed my buddy and told him about the problem I had just seen and suggested that he customize those error messages so that they don’t give out too much information. Needless to say, he got right to work on identifying the problem and limiting the amount of information that was being divulged.

Now, you might say to me, “why would it matter, it was a fairly useless website with no useable information”. I’d tell you that you are right, in the grand scheme of things. Sure, I probably wouldn’t be able to get my hands on any uber-sensitive information. That’s not what is important. What is important is that my buddy who built the site also creates some fairly powerful custom web applications for the government. If his useless website is configured in such a way, is he making the same mistakes when building applications for the people that want to keep the secrets….well, secret?

By offering up an error message like that, an attacker is able to use the information to refine their attacks. In addition to that, we used to have a saying in the Marine Corps when preparing for a wall locker inspection. “If the presentation of the wall locker is such that the inspector doesn’t want to mess it up to inspect it, you’ll do just fine. If it looks like trash, the inspector is going to start digging into things, ultimately finding more problems.” The same idea holds true for attackers. If you present an application or website that doesn’t give away too much information and appears to be well secured, most attackers will move on to the next site. If simple things like error messages divulging tons of information are found, you can bet that the attacker is going to believe that there are other configuration errors and will begin to dig around. We don’t want them doing that, now do we?

I don’t mean to pick on him about this because he is a very good programmer, security savvy and very smart guy. He and I spent many, many hours in the Marine Corps investigating incidents together and solving problems. I simply wanted to use this real world experience to illustrate how important it can be to make sure that your web applications are configured securely. Even if they appear to be useless websites that no one would be interested in, they can lead to attack escalation and possibly compromise.

Over the past year, MSI has performed so many information security assessments that I have lost count. As the Senior Security Engineer and quasi-Project Manager, I get to read each and every report that comes out of our technical team, before it gets shipped off to the client. While we occasionally see things that can only be described as “interesting”, there is usually one constant theme amongst the overwhelming majority of our clients that continues to surprise us AND them….and that’s the use of Microsoft’s Terminal Services.

For those of you that don’t know, Terminal Services is a solution that is designed to allow remote access to the graphical user interface (GUI) of the machine on which it is installed. Terminal Services is probably one of the most convenient solutions around for allowing remote access to a particular system. What continually surprises our clients is the fact that we, as the proverbial attacker, are just as capable of taking advantage of that “convenience” as the administrators who regularly use them are.

For an attacker, Terminal Services does not only provide access to a system’s GUI, given the correct credentials, it also provides a way to verify whether those credentials are legitimate. Here’s the deal, when an individual (or attacker) connects to a Terminal Services login portal, they are authenticating to the local machine OR the domain…dependent only upon their current mood or desire. You see, Terminal Services gives you the option to choose where you wish to authenticate, assuming the target host is configured as part of the domain.

While it might be useful to discuss exactly how an attacker can use Terminal Services against you, I think it’s more useful to discuss how we have seen Terminal Services deployed and what some of the better solutions might be.

We primarily see Terminal Services deployed on an internal network, which is where it was designed to be deployed.  On some rare occasions (much to our delight, our clients dismay) we see Terminal Services deployed on Internet-facing systems. This should be considered an absolute no-no. If an attacker were able to get their hands on legitimate credentials (any credentials that are valid on the target machine or domain, if configured) there is nothing stopping them from gaining access to the GUI on that Internet-facing system.  No need to scan the host for vulnerabilities.  No need to run any exploit code.  No need to set up any netcat shells.  No need to maneuver around the system via the command line.  The attacker can log into the host just as if he were sitting at the keyboard.

The problem with allowing Terminal Services on an internal network is that it simply makes an attackers job much easier than it should be. Again, given legitimate credentials, it becomes trivial for an attacker to move from host to host that has Terminal Services installed.  You can use your imagination to figure out what the attacker does once logged into the hosts.  The big question here is…which systems usually have Terminal Services installed, on an internal network?  In our experience, it’s usually the critical systems that administrators need to work with on a regular basis.  That’s right…domain controllers, mail servers, web servers, database servers, etc.  Many of those systems are usually showered with extra attention to ensure that their patches are current, anti-virus is up to date and logs are analyzed.

If you, the administrator, are dedicating so much time towards keeping those critical systems up-to-date, why keep an authentication portal available that offers no encryption, is vulnerable to man-in-the-middle attacks and grants remote access to the GUI of your most critical systems…all while allowing every single user on the domain to authenticate to the system?

On Internet-facing systems, we would much rather see a VPN solution being used to allow remote access. If a VPN solution cannot be used, we would prefer to see people using some sort of Virtual Network Connection (VNC) or Secure Shell (SSH) solution that encrypts the communication tunnel and authenticates to the service and not the local system or domain.

In both VNC and SSH, a username and password is set when the service is installed and configured.  Those credentials are specific only to the actual remote access service and not the sytem or domain as a whole. So, if an attacker compromises those credentials, they don’t automatically have access to the local system or domain…they are still stuck inside the sandbox of the remote access service.

On internal systems, there is really a couple of ways around the Terminal Services problems. If you are dead set on using Terminal Services, MSI would recommend that you disable the service until use is needed.  At that time, it is possible to start the Terminal Services service, remotely.  Once use has expired, disable the service again. In addition to disabling the service, it is imperative that Terminal Services be configured to only allow administrator accounts to connect and requires a multi-factor authentication token to authenticate. In doing so, you have created a service that is only available when needed and then only to individuals who are administrators AND possess a legitimate token.

The second option would be to use VNC, again.  As mentioned, using VNC instead of Terminal Services allows for credentials to be used that aren’t related to the local system or the domain…only the VNC service.

These are just a couple of ways around using Terminal Services.  A lot of our clients say that they use Terminal Services because it is convenient.  Our answer…yes we know…thank you for the assistance. A lot of times organizations have to try to balance security and convenience in order to allow for functionality. In this particular case, MSI believes that the individuals that normally use the Terminal Services should be technically savvy enough that security can be increased and convenience can be reduced, especially on critical systems.

Then again, if you think your convenience isn’t that big of a security problem, you could always ask us to help validate that theory.  Probably much easier AND cheaper than if a real attacker validates the theory for you.

Business continuity is subject to many unexpected events, one of which is the weather. When New York got covered by 9 feet of snow, practically everyone had to stay home until the roads were clear. But the productivity of some businesses was virtually unphased by the tons of snow because they use secure VPN access to log into their corporate network from the comfort of their own home. VPN, meaning virtual private network, lets packets traverse the Internet encrypted so they cannot be read by malicious entities. The end result is that using a VPN is virtually equivalent to plugging your ethernet cable into the wall.

Of course one wouldn’t want to use one-factor authentication on a resource as valuable to attackers as a VPN, so anyone who accesses the VPN should be required to use multiple-factor authentication. Some businesses implement this with SecurID tokens that change numbers in a pseudorandom fashion, others use certificates that require passwords to unlock them, and some businesses also limit access to the VPN so that only certain whitelisted IP addresses can get in. No matter how you configure it, VPN can save your business big bucks by allowing your workers to be productive from home on snow days.

Last month over two dozen kernel bugs were published on a security researcher’s blog. Most of them were found using a file system fuzzer, which would create malformed file systems to try to crash each kernel. Not all of the MOKB bugs were file system related though. Some problems were found with Apple Airport drivers, Netgear wireless drivers, and Broadcom wireless drivers. Although, now more vulnerabilities are known that could be exploited, this fuzzing approach does improve the overall stability of software available to consumers.

What I wonder, though, is why don’t these big company engineering teams have a process to find all these bugs before the software is put into production? The same free fuzzing tools and techniques are available to the engineers as are available to the underground, so why aren’t they using them as part of their development process at each step along the way? They actually have the source code… so it should be easier!

Big companies have been cutting corners in development, and especially testing, in order to turn a bigger quicker profit for their shareholders. Then, the vulnerabilities always come back to bite them and the consumer who gets exploited.

Eventually, maybe hundreds of years from now, all code will be open source and properly tested. People will realize that it is the only way to have secure software, and better processess will be put in place to ensure stable code. Until then, MO_B’s (Month of ___ Bugs) will be one of the only checks and balances upon the undertested software products being released today. Love them or hate them, security researchers that find these flaws are doing the work that the engineering teams should have done pre-release.

Yes, that is the question. Unfortunately, there is a difference between compliance and security, in terms of Information Security. MSI was recently approached with a simple question concerning multi-factor authentication and what the regulations really are (or will be, for those bodies of legislation that are a little behind the power curve). A quick perusal of several different pieces of regulatory guidance (i.e…NCUA 748 and the FFIEC Handbooks) indicate that, while they each call for the use of multi-factor authentication for high-risk transactions involving access to customer information or the movement of funds to other parties, there is very little guidance that dictates the level or complexity of the proposed authentication scheme.  One “attempt” at guidance says that where a risk assessment has indicated that single-factor authentication is inadequate, financial institutions should implement multi-factor authentication, layered security, or other controls reasonably calculated to mitigate those risks.  What in the world does that mean?  To me, that means that a financial institution, given a third party risk assessment has been completed, can decide to use some implementation of authentication that may not be the most secure, as long as “they” believe it to be reasonable enough.

I currently bank with a financial institution that only requires a username and a password (at least 6 characters, one capital letter, and no special characters allowed) for me to log in to the online banking site and have unfettered access to my account. To me, this is an outrage!  Granted, I can change banks.  Unfortunately, I don’t believe there are very many options that offer a more secure authentication scheme.

At MSI, we set about to try and define our stance on multi-factor authentication and whether simply complying with the regulations is going far enough to secure that precious “member data”. We were asked if, instead of implementing a multi-factor authentication scheme, would a solution that requires the use of a password and a security question (much like the age old “mother’s maiden name” question) would put a financial institution into compliance.  The short answer….yes.  The long answer…depends if the financial institution “believes” it does.  MSI’s answer….not even close.

In these types of situations (where regulatory guidance is too “willy-nilly” to enforce a secure solution) organizations should look to industry standard’s best practices for guidance and implement the secure multi-factor authentication scheme that will go much further in protecting customer data.

Multi-factor authentication is meant to be difficult to circumvent.  It requires the customer to be able to offer AT LEAST 2 of 3 possible forms of proof of identity.  Those forms are (in no certain order):

1. Something you know (password, PIN)
2. Something you have (ATM Card, Token, Smart Card)
3. Something you are (Biometrics…fingerprint, hand print, retinal scan)

While ATM’s have been using multi-factor authentication schemes since the beginning of time (at least for those Laguna Beach watchers in our audience), financial institutions continue to leave the most critical of vulnerabilities unchecked.  That’s the vulnerability of an attacker exploiting the inability of a customer to keep their passwords to themselves. If those same financial institutions took that leap to offer a more secure authentication scheme, I believe the market would reward them handsomely.  They’d get my money, as measly as the balance may be.

The moral of the story is that multi-factor authentication is meant to be difficult for all parties involved.  Sure, all I hear is that security departments don’t want to hinder their customer’s or their employee’s ability to perform their work by requiring a difficult authentication scheme.  That’s the biggest complaint that surrounds multi-factor authentication. However, if it’s easy for your customers to use, it’s probably pretty darn easy for an attacker to use as well.

While the current regulations give many financial institutions a “cop-out” when deciding whether or not to implement a multi-factor authentication scheme, it should not mean that the bottom line should always be the deciding factor when protecting your customer’s personal information. Industry standard’s best practices should drive this moral dilemma. A risk assessment, performed by a qualified third party, may indicate that the risk doesn’t require a tough authentication scheme.  I have to wonder if that risk assessment bothered to contact any or all of the 10’s of thousands of people who have fallen victim to fraud or identity crimes because of poor authentication requirements?

As with a chain, so also with security: it only takes one weak link to cause a catastrophic Information Security Incident that leads to the theft of confidential customer data, loss of reputation and/or money.

Your company could have a bulletproof security policy on paper, but if no one in your organization is putting it into practice, or if a few people are cutting corners to save time, then that puts everyone at risk. A Kevlar vest does you no good against attackers unless you wear it.

So ask yourself: Am I the weakest link in my organization’s security? If not, how can I strengthen the other links through educating them? See if any of these apply to you or those around you, and strengthen the security chain against attackers.

• Do you throw away business documents without shredding them?
• Do you keep all your passwords in an unencrypted file called Passwords.doc in your My Documents folder or on your Desktop?
• Do you hide your passwords on a post-it note under your keyboard, under a coffee mug, on the wall, or anywhere for that matter?
• Do you use the same password for absolutely everything and never change it? Or if you do change it, do you only change a single digit?
• Do you open any attachment or follow any link that comes in your email inbox?

These are basic security mistakes that could lead to you becoming your organization’s weakest security link. Avoid these habits like the plague, and make sure none of your coworkers are doing this either. Read your company’s security policy, and follow it. Educate and implement.

Here are a few steps you can take to strengthen your security today:

• Install encryption software and use it to encrypt your Passwords.doc
• Use password-generating software like Personal Security Assistant to make totally random passwords.
• Utilize the shredder so that document reassembly will be a nightmare.
• If you don’t know who sent you an email, then don’t run the binary!!
• Store important files in an encrypted hard drive if the security policy allows it.

Don’t allow yourself to become the weakest link.

In this day and age, almost anyone can invade your computer system and steal your data. This makes it all the more essential to ensure that beyond your perimeter network security barrier, you have a line of defense inside your system. That line of defense is encryption. Storing data unencrypted on your hard drive isn’t a mortal sin, but it could come back to bite you some day, so today we’re going to discuss that last line of digital defense.

There are two cryptodrive systems which have the biggest market share today: TrueCrypt and PGPDisk. Each has a number of advantages and disadvantages, but both share the quality of keeping your data secret from prying eyes (except when the drive is mounted). Whether you’re just storing your family photos or your customers’ credit card data, using this highly advanced technology is a must in today’s world.

I think TrueCrypt has 6 advantages over PGPDisk: 1) It’s open-source. 2) It’s free. 3) It’s cross-platform. 4) It can contain two volumes, accessed by different passphrases (or keyfiles), or you can have it only contain one “visible” volume. Anyone analyzing the bits of the unmounted drive/file cannot tell if there are one or two volumes, so 4) there is plausible deniability of the hidden volume (which TrueCrypt stores at the end of the big cryptofile.) 5) You can choose from a bunch of encryption and hash algorithms to suit your personal preferences. 6) There are absolutely positively no back-doors built-in (see #1: open-source). On top of all that, installation and use is mind-numbingly simple, especially on Windows machines. It’s hard to deny that TrueCrypt is an amazing technology.

For added security, you could even store PGP-encrypted files INSIDE of your TrueCrypt drive(s), and keep no plain-text files in there. Your mileage and paranoia may vary, but that sort of dual-encryption scheme will eliminate the problem where a mounted encrypted drive can be accessed just like a normal drive. Just because you want 1 file in the encrypted drive doesn’t mean an attacker should be able to get to all the files in there.

PGPDisk is no slacker either though… Even though it isn’t free and it isn’t open-source, its very fast and builds itself into the Windows shell quite seamlessly. It has great options. You can have it mount your encrypted drives at startup if you want, and auto-unmount automatically after however many minutes or at system standby. It can use any number of your existing PGP keys to access the database, so the drive could be accessed by 20 people if you want, and/or you could just use a passphrase not associated with a PGP key. This is possible because the PGP keys and/or passphrase unlock the master-key, and that master-key actually encrypts and decrypts the disk. So when you type in your PGP passphrase you are actually unlocking another master-key that does the dirty work. PGPDisk is for Windows only, so that is definitely one thing to keep in mind when picking which solution you want to go with. Also, it can’t be proven if PGPDisk has a backdoor or not, since it is closed-source, but crypto experts agree it is safe.

Also, it is best to keep your encrypted drive/file on a (1 gigabyte?) USB flash drive, and keep a backup of it on a CD or DVD. When creating your encrypted drive, 640mb is a good size to select since then you can back it up to a CDROM easily and you won’t have to worry about splitting the file onto 2 CDs.

One of the best reasons to use TrueCrypt is it’s cross-platform capability. You could be running a Microsoft Windows machine, and have Ubuntu running in a VMWare image, and both your VMWare and your real machine would be able to get to the data.

Also, on a bit of a side-note, if you’re using Windows it is a really good idea to do all of your web-surfing in the VM image instead of in Windows itself. Then, if you’re surfing along the net with Firefox in the Ubuntu VM image, and you get hit by a zero-day browser exploit, the effects stay trapped in the VM image. Then, since your real data is in the encrypted drive, and your real system is unaffected, its just a matter of getting a fresh VM image and you’re good to go again.

Information security doesn’t stop at the network perimeter, it stops at the bits of juicy data that the attacker wants to steal. Use encryption, use VM images – they are your friend. The digital future is shaping up to be a very hostile place for novices, so educate yourself and your friends now to avoid getting stung later.