Scorpion Software
   Home  |  Products  |  Sales  |  Service and Support  |  Blog  |  Contact Us  |  Company 

Scorpion Software Corporate Weblog

July 17, 2008

Whitepaper: The Five Failings of Password Security, and How you can Handle It

Password security is one of the weakest forms of user authentication in the industry. Yet businesses continue to use passwords to protect their most important corporate data. These passwords are the keys you use to access your personal and corporate data anywhere in the world. It might be for accounts local on your computer, or could be your confidential customer data that may be hosted with a provider online. They are used everywhere, which has been a great advantage to business productivity and access, while at the same time also becoming a great liability.

Download our latest white paper to learn why passwords alone may be a large risk to your business, and show how two-factor authentication and identity assurance can help to protect your business against attacks to weak, shared or stolen passwords.

You can download it here.

Posted by Dana Epp at 01:09 PM | Comments (0) | TrackBack

May 28, 2008

Participate in our AuthAnvil Product Integration Survey

This invitation is to participate in our extremely short product integration survey to enable us to better understand what software you use on a regular basis. The results from this survey will help us to plan product integration strategies with fellow software vendors who are interested in adding more security and value into their own offerings.

We cannot promise will we get AuthAnvil authentication integrated into all these products. However, your feedback will help us to communicate your interest with these vendors, and allow us to determine where we should focus our efforts. Imagine using your AuthAnvil token to log into all your LOB applications you use on a regular basis!

Your feedback is invaluable to us, and we thank you in advance for your help.

Take this survey >

Posted by Dana Epp at 12:51 PM | Comments (0) | TrackBack

May 05, 2008

Scorpion Software announces new AuthAnvil Partner Branding

Thank you.

Thank you to all our partners who have been working hard to deliver AuthAnvil solutions to your clients.

We now are represented in 10 different countries, and are now represented in so many interesting and different verticals, we are starting to lose count. As part of our commitment to drive revenue opportunities to our partners, we continue to refine our partner program in a way to add real value to your business, and your partnership with us.

One thing you guys have been asking for is new brand awareness about our partner program and your status, including better materials for your own website and partner logos. You can visit the Partner Portal to download the latest materials to aid in that. Of particular interest is the new rebranded partner logos:





The last logo is interesting. Based on the continued requests by our partners who are integrating AuthAnvil strong authentication into their own applications (or applications they install and distribute), Scorpion Software will issue "AuthAnvil Protected Solution" status to vendors who have shown their product to work with ours.

Over the next year we hope to build a catalog of "Protected Solutions" so you and your clients can be assured your investment in AuthAnvil can carry on to complimentary products. if you have a solution you would like tested, please get in touch with us.

Thanks again for all the partner feedback on how we can refine our program. We hope the new branding will aid our partners as we continue to gain more mindshare in the market place.

Posted by Dana Epp at 03:07 PM | Comments (0) | TrackBack

May 02, 2008

Are you happy with how UPS delivers our product?

Call me nostalgic, but I have always been a fan of UPS. As a teenager, I worked in their sorting centre in Calgary for a short period of time. They sponsored me when my soccer team went to the provincials, and I always liked the people and culture of the company.

When I was initially building Scorpion Software, I interviewed all the major shipping organizations, to make sure I was selecting the best shipping provider for our business. After all, whomever I chose would become an extension of Scorpion Software, being the first thing our customers experience when they receive our products.

I ultimately decided to go with UPS because I knew I could count on them. They treated me with respect and didn't make me feel unwelcome. That was in total contrast from other carriers such as FedEx where they felt we were too small to be worth an actual face to face interview. And over the past year, the experience has shown UPS works really hard for us.

Recently though, I have had an experience that shocked me so much, I am starting to wonder if I made the right decision. Between US Customs brokerage/billing problems and poor delivery service, I am wondering if you as my customers are getting the service you deserve.

Today takes the cake. I recently ordered more gray pack (the gray envelope our product comes in), only to find that on delivery, it was torn to shreds, with the contents MELTED together from extreme pressure. I can't believe this. It's their own product, and it's being delivered to me like this.

That picture doesn't do it justice of just how ripped up this thing is. I can't believe the UPS driver would even leave it.

I'm concerned. If they are willing to deliver their own product in such a state, just how are our packages arriving to you? If you feel that UPS hasn't fulfilled their role as a trusted carrier of our goods, I want to know. Please send me an email to dana@scorpionsoft.com and include a picture of how your product has arrived. If it hasn't arrived in an acceptable state, I will make sure you are taken care.

Of course, if you feel UPS has gone out of their way to help you, I also want to know about it. My goal is to make sure your experience with our company exceeds your expectations. I welcome your comments and suggestions as to how we can improve your experience working with our company, our products and our partners. Including UPS.

Posted by Dana Epp at 04:04 PM | Comments (0) | TrackBack

March 21, 2008

Providing stronger centralized remote administrative access to Windows networks

Eriq Neale over at EON Consulting is a customer of ours who, like many of you, has concerns when it comes to opening RDP (port 3389) to his client networks. When managing a lot of client sites remotely, it can be daunting to create a proper protection profile to limit access appropriately for your staff, while removing such access from the threat landscape that makes up the Internet.

I was pleased to see Eriq talk openly about how they secure RDP access with AuthAnvil over there, and I encourage you to go read the approach they took on his OnQ blog. I was really impressed with how he summed up the benefits he gets from AuthAnvil:

  • Local access to the sever is still possible with the Administrator account and no security token.
  • Remote access to the server is limited to the secondary administrative account, which also requires the use of a security token to successfully log in.
  • The access logging in AuthAnvil gives me an accurate accounting of which of my staff accessed one of our support servers and when.
  • When staff turnover occurs, access to remote systems is denied in a single step by disabling the employee's token in the main AuthAnvil system.

When you need to manage HR issues to remote client sites, AuthAnvil can work rather well. With no extra licensing costs on the number of servers or workstations the software runs on, it's rather easy to deploy strong two-factor authentication to limit your exposure to client networks. When staff change roles or turn over, by simply revoking their token at the central AuthAnvil SAS you simultaneously block them from accessing all remote sites. Never mind your own. Instantly.

Now you no longer have to be so reactionary when the HR incident occurs. You don't have to rush out to all client sites to change administrative passwords. That saves you a lot of money on non-billable time you would normally have to spend dealing with this issue. Many of our customers recoup the cost for AuthAnvil the FIRST time they deal with staff changes. Talk about a great ROI!

Thanks to Eriq for such a great post. And also to his other post where he praises us for our service:

It's clear to me that some vendors "get" service while others do not. Dana and the rest of the staff at Scorpion Software get it. They have embraced the SMB market, and even though their product is head and shoulders above the competition, they've not developed an attitude about it. I've learned a few things in my interactions with Scorpion, and I'm going to try to incorporate a couple of elements of those experiences into the way we run our operation, so that we can continue to provide outstanding service to the clients we work with.

Awww... you made me blush. We appreciate your business Eriq. And I am flattered that you feel that we are providing outstanding service. It's amazing what happens when you have a corporate culture that treats that as the norm, and not some foreign event.

I think that might come from the Strategic Objective that I set for my company from the on-set. I wouldn't normally share this with the world, but I think that this is a special case that warrants the openness. Here is the relevant paragraph from Scorpion Software's Strategic Objective:

Our mantra of "Custodit Nuntium" (Protect Information) is core to our Code of Ethics and we will put the protection of our customers before the protection of our profits, while still being responsible to our stakeholders in the business. The success of our company is through the success of our customers, and every aspect of our business will be focused on refining processes to achieve this.

I don't show you that to impress you, but impress upon you that this is what makes up our belief system here. Eriq isn't having a unique experience, and I am pleased to see he is successfully using our products to protect his own business, and that of his clients.

So the real question is, when are you going to start deploying AuthAnvil in the same manner? You can start by reading our AuthAnvil Multi-Site Configuration Guide.

Posted by Dana Epp at 02:10 PM | Comments (0) | TrackBack

March 16, 2008

Did Google miss the OpenID boat when they deployed 2FA this week?

So this week Google announced that it will be using a form of two-factor authentication for it's premier customers using Google Apps. Once registered, Google Apps will validate their credentials along with an encrypted file stored to disk on the customer's computer. If the user tries to log in from a foerign host where this file does not exist, they will be challenged with pre-determined questions such as "What high school did you attend?". This adds another factor during the authentication process, and makes it much more difficult to gain access.

It is an interesting approach, and very cost effective. (It's like a $1 a month for the new service). But is it strong enough? An adversary from a remote computer does not NEED the encrypted file to get in if he can answer the challenge questions. Questions you can ferret out with social engineering. Let's "face" it... it's not hard anymore to find out what school someone went to if they are on Facebook.

I applaud Google for making access to their online apps more difficult to gain access to with this new layer of defense. For the cost of the solution, it does reduce the risks to some forms of automated collection and attack. But I do not believe a motivated adversary focusing on a target will be deterred by the extra security question(s). You would be better off challenging them with a one-time-password generated from some 2FA server where a physical device has to be present for the login to occur.

If Google wants to make some real intersting inroads when it comes to adding strong authentication to it's premium apps, I encourage them to consider some of the other technology that exists out there like OpenID. In this way, credential management can be handled by other identity providers that might offer stronger solutions such as Cardspace or our own AuthAnvil Strong Authentication System. Heck even companies like Arcot (the company behind Google's new 2FA) could build support in as an OpenID provider to give the same level of authentication as we now see in this new system, but departmentalized so customers wanting stronger authentication could do so with other providers.

As more companies realize the benefits of online applications, on-demand authentication is going to become more interesting. Web apps will need to embrace departmentalized identity providers so that companies can manage their employee credentials across multiple, unrelated systems. Google had the perfect opportunity to embrace this in their apps. It is too bad they chose this approach.

Posted by Dana Epp at 05:17 PM | Comments (0) | TrackBack

March 06, 2008

Understanding why OTP complexity matters

Recently when talking with a potential customer we got onto the topic of the use of one-time-passwords (OTPs) that use 6 digits. The discussion surrounded around whether they were viable, and why Scorpion Software doesn't use such tokens, since they can be significantly cheaper than what we pay for our more complex 8 alpha-numeric OTP tokens.

It's an interesting question that I thought I would share with everyone. It's all about the "keyscape". Or in other words, the number of different possible permutations that can be produced by the token.

The calculation of a token's keyscape is represented mathematically using the formula X^N, where X is the number of possible values and N is the length of the password. As such, the potential keyscape of a 6 digit OTP is 10^6, or 1,000,000 possible values.

Now consider our token keyspace. We use an OTP that is 8 characters in length and is a combination of the English alphabet and the normal 10 digits that other token vendors use. That means an AuthAnvil token calculates out to 36^8, or 2,821,109,907,456 possible values. Yes, that's right. 2.8 TRILLION.

When we look at security here we balance usability and cost against the effective strength it will provide. It was our decision that we would rather pay double for a token that could offer SIGNIFCANTLY stronger OTPs, than to go cheap to save our customers a couple of bucks and expose them to more risk.

So there you have it. Consider how quickly a computer could brute force 1,000,000 permutations against 2.8 trillion. Add to it the 4 to 8 digit PIN that we also require that many other vendors do not, and you now see why it becomes extremely easy to make that decision. Yes, we make you type in TWO extra keystrokes and have to use more of the keyboard... but it seems like a small price to pay for the extremely high benefits from our approach.

Now to be fair, this doesn't mean that 6 digit OTPs are not strong. One-time-passwords are MUCH better than static reusable passwords at any reasonable length. But numbers don't lie. I'll take 2.8 trillion permutations any day.

How about you?

Posted by Dana Epp at 04:40 PM | Comments (0) | TrackBack

February 25, 2008

AuthAnvil in the News!

What a treat. Found out that the SMB Partner Community Magazine published by SMB Nation recently featured our AuthAnvil v1.5 release in the Technology Watch column in their latest issue of their magazine.



Harry was nice enough to get me a reprint PDF so you can see the column yourself if you don't subscribe to the magazine. You can download it here.

Thanks Harry!

Posted by Dana Epp at 10:12 AM | Comments (0) | TrackBack

January 08, 2008

Career Opportunity: A driven sales associate with a passion to help small businesses

Scorpion Software is looking for talented people that can help us to consistently deliver on our promise to create strong authentication and identity assurance solutions for small business. If you have a passion to help people, and want to work in flexible and casual environment that still means business, then please consider checking out the following job posting we have available:

Sales Associate

Department: Sales
Posting Date: January 2008
Reports to: VP of Sales
Job Location: Chilliwack, BC, Canada

Job Summary:
Our goal at Scorpion Software is to make strong authentication and identity assurance accessible and usable for small business. As a Sales Associate you will help customers understand how Scorpion Software can help them to reduce the risk of unauthorized access to privileged information assets, and show them how we can remedy their pain points as it relates to remote access.

This role is responsible for growing the sales of our AuthAnvil solutions worldwide. This role will create and manage the business sales and development process, and includes finding new customers, developing and training them in the use of AuthAnvil, working on opportunities with partners and assisting them to close business.

Key Responsibilities:

  • Drive new customer and partner development and sign-ups.
  • Drive product promotions and programs.
  • Identify and cultivate sales growth opportunities in existing accounts as well as new accounts.
  • Create and analyze sales reports, identify issues contributing to success or shortcomings and take any corrective action.
  • Accurately report sales activity and forecast sales.
  • Support partners in appropriate sales opportunities.

Preferred Job Skills:

  • Possess a strong understanding of the sales process.
  • Proven track record of achieving sales targets.
  • Detail orientated with strong follow-up skills.
  • Strong negotiating skills with ability to close sales.
  • Excellent communications skills, both verbal and written.
  • Ability to be productive in a globally distributed team through self-discipline and self-motivation.

Special Considerations:

  • Flexible work hours ideal for a parent with children in school.
  • Opportunities to telecommute on a semi-regular basis.
  • Deep technical knowledge NOT a requirement. We will provide training.
  • Profit sharing commission structure above normal remuneration.

Candidates interested in an opportunity to learn, be challenged and strive for excellence are encouraged to apply. Any interested parties should submit their resume by email before January 31st, 2008 to iwannawork@scorpionsoft.com. We thank all those who apply. However, only those candidates selected for an interview will be contacted.

Posted by Dana Epp at 11:00 PM | TrackBack

December 02, 2007

Tracking who is accessing corporate resources with RWW

Susan Bradley blogged about how she uses RWW-Guard to monitor who is logging in via Remote Web Workplace (RWW) on SBS 2003. I love seeing comments like this, as it shows real world usage of our products in the field in a way that solves real pain points for our customers.

She also blogged how you can try to get the information manually. Not as pretty. And doesn't offer you clear visualization of the events.

So if you want to know WHO is coming into your network via RWW, WHERE they are coming in from, and WHEN they do it, check our RWW-Guard. It's a great tool for this sort of thing, and allows you to add strong authentication to boot (assuming you have a SAS like AuthAnvil)!

Posted by Dana Epp at 02:23 PM | Comments (0) | TrackBack

May 22, 2007

Where information security meets IT operations... disaster planning for risk and crisis recovery

So at the end of the week I will be down in New Orleans sitting on a few leadership panels at the "Small Business IT Disaster Planning for Risk and Crisis Recovery" conference. I think it is a fitting location for such a conference, especially with the results of Katrina a few years back.

Some of the sessions are going to be very interesting. From virtualization and backups to access control, there is quite a bit to learn from when it comes to mitigating risk in the face of disaster. There is something for everyone, and is an event you shouldn't miss.

The format is quite interesting as well. This isn't about slidedecks and single people speaking TO the audience. It's about a leadership panel that communicate WITH the audience to answer questions and explore issues facing our organizations today.

If you are going to be going down, let me know. Maybe we can hook up during the conference, or go check out the jazz scene in the evening. If you would like some personal one-on-one time to discuss AuthAnvil, drop me a line and we can set something up.

Posted by Dana Epp at 09:38 PM | Comments (0) | TrackBack

July 18, 2006

Requests to join the RWW-OTP beta

Hey guys,

Just to keep a heads up. Yesterday in our newsletter there was some information on joining the RWW-OTP beta. I want to personally thank everyone who has replied to that call... its been overwhelming. So overwhelming in fact that I simply can't answer each and every one of you in what I would consider a responsible time frame.

I have received your request, and have added you to the list. Although I haven't responded, that doesn't mean you are not in. Before the end of the month I will add a new forum for RWW-OTP and those who are chosen for the closed beta will be emailed with information on how to log on.

Looks like RWW-OTP has more early interest than we originally thought. Thanks again for all the responses. We want as much community involvement as we can get, and we want to include as many of you as we can. Our goal is to get great testers with tonnes of great feedback on how to make the product better.

Posted by Dana Epp at 10:34 AM | Comments (1) | TrackBack

April 18, 2006

Download Manager updated to fix *.exe extension problem for Internet Explorer users

The worst thing that could happen to a developer is to receive a bug reported that just can't be reproduced. Its ugly as it is so uncomfortable to say to the reporter "works for me" over and over again, knowing a problem exists, but that you can't see it.

Lately, I have been going through that when people download the Firewall Dashboard with SOME versions of Internet Explorer. I say some versions, as many people don't have problems. I can't explain it, its just crazy. When someone would download the file and be prompted to save it, it wouldn't include the *.exe extension. So when complete, the file would SEEM to be corrupt, when all that was wrong was that it had to be renamed with the exe extension.

Talk about frustrating.

Anyways, this morning we got another 3 reports of it and I said that was enough. So I called up a dev friend of mine and we went through the headers line by line trying to see what was different between different versions of IE and a browser that always worked (aka Firefox). Ends up that some patched versions of IE deal with the content-type differently, as well as the content-disposition. Oh what a headache.

Long story short, we were able to FINALLY figure out the problem, and have now updated the Download Manager. As such, customers should no longer have any problems downloading exe files from our servers. If you do, PLEASE let Customer Support know right away.

Posted by Dana Epp at 12:01 PM | Comments (0) | TrackBack

April 05, 2006

Interesting insights about the FWDB while at SMBTN

Presenting on "Firewall Analytics for SBS 2003" was in itself a fun experience while attending the SMBTN Spring Conference. However, a more compelling set of insights came after the presentation, when a bunch of attendees downloaded the Firewall Dashboard to their own SBS boxes and installed it right there and then. I had a few people come up to me with the laptops and show me the results they were immediately getting.

Some insights from those interactions:

  • Linksys routers suck. Two different people came to me with similar network problems that Susan Bradley saw when she first installed the Firewall Dashboard. Boat loads of router packets banging on the SBS box. When you go into the configuration, even though dynamic routing is turned off, it is STILL SENDING the packets. Wow. That's ugly.
  • Fortinet SAYS they support WELF, but it's their own version of the standard. It is a very subtle difference, but enough that our current WELF parser will not accept it. As a result, I am going to write a new parsing plugin using a more "generic" WELF format that will be a little less aggressive in the regular expression parsing of the data. This will then support Fortigate firewalls natively, and other firewalls that aren't so strict with following the WELF standards.
  • I am impressed with some of the deployment scenarios I am seeing in the field that we don't currently support. My favorite is pointing multiple ISA servers to log to a single remote SQL server source. Removes the overhead in MSDE on the SBS box, while allowing correlation of multiple logging sources. I like it so much, that we already have an alpha build of a remote SQL server parsing plugin. We hope to have a beta for it next week.

I received some interesting feedback through this process. And I found it a lot of fun interacting with potential customers at the conference in this manner. Thanks to SMBTN for asking me to come down. It was a great experience.

Posted by Dana Epp at 09:21 AM | Comments (0) | TrackBack

March 24, 2006

Kind words about the release of Firewall Dashboard

Hey, nothing feels great like reading someone else say nice things about your product.

I loved hearing from Amy Babinchak (ISA MVP) on her blog that:

Fellow MVP Dana Epp has created a useful add-on tool for ISA. It's a Firewall Dashboard application that takes the ISA logs and presents the information in an easy to use graphic format. You can also configure it to send you a report on your firewall activity daily. It's a nice addition to the native monitoring tools built into ISA. I've been using the Beta and have found it easy to install and the reports easy to configure and understand. You'll learn things you never knew about your firewall. Why didn't you know? Because you weren't looking. Scorpion Software's Firewall Dashboard makes it easy to look.

Great point Amy! The information is there. But when you have thousands and thousands of firewall events, how do you find out what really matters? Thats exactly what the Firewall Dashboard is for.

Susan Bradley (SBS MVP) had some kind words to say too:

Today [Dana's] gone from being a security friend and guru, to a Small Business Security guru. It's cool to see [Firewall Dashboard] come to the marketplace. I find that it adds a great deal to my already daily routine of my morning email.... in the next phase, SBS 2003 R2 will give me "green checks" in my daily email. But today, I get blue magnifying glass every day at 6 a.m that keeps me aware and is part of that "hardening me" the business owner process.

Being called a guru by Susan is a treat in itself. But being called a "Small Business Security guru" by the SBS Diva herself... wow.

So where to now? Well, with the blue shield with the magnifying glass now out, its time to go to the black shield with the radar on it. What's that you ask? You will have to wait and find out. Some of you will be invited to the private beta soon enough. :)

Posted by Dana Epp at 03:20 PM | Comments (0) | TrackBack

March 19, 2006

Scorpion Software featured over at AutomatedQA

If you have ever wondered what sort of development and quality assurance processes we have in place around here, you now have an opportunity to see for yourself in a case study AutomatedQA has completed with us. After what seemed to be a long interview of questions, AutomatedQA has created a detailed case study on how we use their automated testing tools as part of our software development life cycle.

We are able to do a lot more, with a lot less, thanks to their tools. It saves us alot of time and effort which reduces our costs and keeps our people focused on building stuff that matters to our customers. I was only happy to offer my support in backing their product with a case study. Feel free to go check it out yourself if you have any interest in knowing how we use their tools, and how you too might be able to benefit from AutomatedQA's products if you are in the software industry.

Posted by Dana Epp at 09:06 AM | Comments (1) | TrackBack

February 12, 2006

Sneak peak of the Firewall Dashboard's New Logo

With the commercial release quickly coming upon us, I thought I would let you in on a little secret. The Firewall Dashboard is getting new branding. In the last couple of weeks we have revealed the logo to some people in our circle of influence and opened a conversation about it. Design, colour and shape all came into play, and we got some GREAT feedback that formed the final version. I was going to surprise everyone and just put it in the last beta shipping in the next week or two. But I just can't wait. I want to let you guys in and get a sneak peak.

So here it is:

As a firewall analytics tools, the Firewall Dashboard is much better positioned with the logo above. Look forward to seeing it in the next release!

What do you think? Like it? Hate it? Don't care? Let me know. Feel free to comment here or send me an email at dana@scorpionsoft.com.

Posted by Dana Epp at 09:23 AM | Comments (0) | TrackBack

January 14, 2006

Using W3C Log file format for ISA 2004 with the Firewall Dashboard? READ THIS!

Doh!

I was adding a new feature in the Firewall Dashboard today allowing you to not only generate yesterday's reports, but the ability to generate up-to-date reports for today and up to a week back. Everything seemed to be working well with ISA 2004 in MSDE mode and I decided to go test it against all the other firewall import parsers. First was the WELF format plugin. Worked great. My Sonicwall firewall reports are displaying correctly. Then the ISA 2004 W3C Log file parser. At 2pm I was seeing firewall events at 10pm. What the h*&k?? ISA is good, but predicting the future???

Uh oh. Although ISA 2004 stores the firewall events in local time for the MSDE records, it uses GMT time for W3C logs. That means that reports begin generated will be time shifted by your local time zone. In my case, living in the PST time zone my reports are shifted by 8 hours!!!!

What does this mean? Well, if you are using the ISA 2004 Log File (W3C) Log parsing plugin, your reports are currently incorrectly being displayed by the number of hours off of GMT that you are. I am surprised none of us caught this during the beta!

PLEASE NOTE: This is only an issue with the ISA 2004 W3C Log file parser. The ISA 2004 DB Parser and the WELF parser are working properly, and do NOT suffer from this issue.

Anyways, test cases for this issue have been built and the bug is now being tracked as Case 137 in FogBugz. We will have a fix for this issue in the next Beta v0.90 release due out in the next week or two. Until then you will have to remember that your reports are shifted by the number of hours off of GMT that you are.

Interesting bug. Funny that it took a new feature like building up to date reports to ferret this out. Hopefully this is the last big issue we will see with the W3C log format parser.

Posted by Dana Epp at 08:22 PM | Comments (0) | TrackBack

December 24, 2005

Happy Holidays!

To all our friends, colleagues and customers, Scorpion Software wishes you a Happy Holidays and a joyous New Year.

Thank you for your friendship and support. May the holiday season bring you wonderous fulfillment and great joy.

With my most sincere thanks and gratitude,

Dana

Posted by Dana Epp at 02:42 PM | Comments (0) | TrackBack

May 31, 2005

Introduction to our newest team members

In the midst of finally getting them settled in, I thought I would take this time to introduce everyone to two of our latest additions to our team.

Welcome to Murray Fleming and Steven Bittner, our most recent summer interns. I can already tell these guys are probably going to be offered a full time gig here... they are real go getters. (BTW, you can stop sending resumes in now please. The positions are filled).

Murray joins us from studying Software Assurance at BCIT and is working as a Quality Assurance Test Specialist, focusing on building out our automated testing framework for all products that we ship. The continued evolution and refinement of our testing framework only increases the quality control we can offer our customers in our products, and I think you will be pleasantly surprised in the next major release coming this fall.

Steven joins our team as a Protection Profile Analyst. With a previous background working for me in quality assurance on other security projects, Steven is tasked with leveraging our custom security tools to build an extensive knowledgebase on how to apply "least privilege" security rights to applications within the Microsoft Windows platform and will be building protection profile templates for various commercial products used in both the small to medium business and enterprise workspaces.

This summer will be a busy one for them. They are already into week two, and are starting to only begin to realize the depth of what they can offer the team, and the experience that are going to gain here.

So welcome to the team guys.

Posted by Dana Epp at 08:00 AM | Comments (1) | TrackBack

May 09, 2005

The Great Intrusion Prevention Debate

InfoWorld is running an interesting point/counterpoint article on "The Great Intrusion Prevention Debate".

Quoting from their description of the article:


No security topic generates more spirited debate than intrusion prevention. Deployed on the edge -- and increasingly, deep inside -- the network, IPSes (intrusion prevention systems) purport to identify and stop attacks before they start based on constantly updated threat profiles. In this Point/Counterpoint, we've pitted Marc Willebeek-LeMair, CTO and Chief Strategy Officer of 3Com's security division, TippingPoint, against Martin Roesch, CTO and founder of Sourcefire (and the inventor of Snort). TippingPoint's Willebeek-LeMair is bullish on the supreme effectiveness of his IPS approach; Sourcefire's Roesch positions IPSes, which his company also sells, as just one component of an integrated network defense system. The clash of these two partisans reveals much about the state of network protection and the rivalry between hardware and software security vendors.

It is interesting to see the two sides discuss the merits of their solutions. What is more interesting is that they are both right... and yet are both wrong. Weird how that comes about.

Let me explain.

First off, I know I sound like a parrot when I say "security is a process, not a product". But its true. It was true years ago when Bruce Schneier first said it, and it is still true to this day. No matter what you deploy (IDS/IPS) its only one piece of the puzzle. ESPECIALLY when you try to apply this to the network. Why? Because the last line of defense is the HOST, NOT the network. And what's more, trying to use behavioural blocking based on anomoly detection at the network level is limited at its best. You need to control the behaviour in the operating system, as the hostile code attempts to actually execute. How can a network based IPS hope to properly filter application level behaviours when they are typically filtering at the network layer, with some limited inspection of the payload destined for applications that aren't encrypted. Oh, the network IDS and IPS vendors you bought product from didn't tell you? They can't actually do anything inside encrypted payloads like SSL/HTTPS/PPTP/IPSec without funky proxying that isn't practical in most environments. The same protocols that make up the majority of sensitive network traffic that these devices are supposed to protect. And to top it off, it requires that the packets go through the device in the first place. That usually means that in most networks, its rendered useless against the internal threat.

Host Intrusion Prevention Systems (HIPS) are another piece of the defense in depth pie. Along side of properly tuned IDS to block known attacks on the inside of the firewall, HIPS can actually control the behaviours on the host... where the attack actually happens. Where it is more realistic to create whitelists of known GOOD behaviours and actually STOP unknown (and possibly malicious) BAD behaviours that are anomalous to the normal operations on how an application works. Thats what a Host IPS is all about!

All in all, an interesting debate. If you are wondering about the merits of network based IDS or IPS, take a moment to read InfoWorld's article. You might be surprised at the points brought forth.

Posted by Dana Epp at 11:29 AM | Comments (0) | TrackBack

April 25, 2005

Security Resource for Small Business

Microsoft has recently partnered up with the US Chamber of Commerce to publish some great security materials for small business.

From their website:

We know how much security and dependability mean to you in today's business computing environment. And we want to help. That's why we have partnered with Microsoft to bring you free technology resources to get tips, tricks, and how-to information you can use right away to help protect your computers and your business. Learn how to best:
  • Protect your network against the most common threats
  • Guard valuable business information
  • Thwart viruses and hackers
  • Plus pointers to additional security resources

You will find an excellent Security Guide for Small Business that helps explain why security is important to your business and outlines steps to better security. They have even published a great Interactive Security Video that allows you to hear expert tips, take a quiz, and build a security plan.

There is a wealth of knowledge in their Security Portal for Small Business. Make sure you take some time and check it out!

Posted by Dana Epp at 04:08 PM | Comments (0) | TrackBack

April 08, 2005

The "Higher Security Mindset" - Seven Best Practices to Keep you Safe

I regularly receive a couple of emails in regards to our views on what we refer to as the "higher level" of thinking when it comes to information security. The question in these emails asks just what higher level means... and what it consists of.

I wish I could take credit for this type of thinking, but it really was taught to me by Kevin Day. However, I don't mind passing it on to you to further that knowledge to others. Most of this is ripped from his book "Inside the Security Mind", and I highly recommend you check out the book if you don't already own it.

When looking at infosec as a whole, we got to stop worrying about the next wiz bang security tool and start thinking about security best practices that when followed, will help to keep an organization safe. Even though the security landscape is constantly changing, these practices (when applied) will adapt to the highly dynamic nature of information warfare and allow you to repel your adversaries without much incident. And that is what makes a higher security mindset.

So lets talk about seven best practices, that when applied, will do more to protect you than running to buy the next wiz bang security tool uninformed.

Think in terms of Zones

Zoning is the process in which you define and isolate different subjects and objects based on their unique security requirements. For those uninitiated to the terms, a "subject" is a person, place or thing gaining access. An "object" is the person, place or think the subject is gaining access to. I use the terms generically since when zoning you really could be applying it to anything. A file, a server, or even the physical access to your safe. You have probably seen the concept of zoning in Internet Explorer where Microsoft breaks zones down into the Internet, Local Intranet, Trusted Sites and Restricted Sites. This is just one example of how you can break something into zones. Of course the concept of zoning can be applied anywhere, as long as each zone treats security in a different manner.

Although I have seen most people think of zones in a network-centric manner, it doesn't have to be. It could apply to applications, physical areas and even employee interactions with others as a defense against social engineering tactics.

Anyways, a zone is a grouping of resources that have a similar security profile. In other words, it has similar risks, trust levels, exposures and/or security needs. For example, an Internet facing web server will have a different trust and exposure level than an intranet web site. As such, the two should be in different zones. Though you can have umpteen different zones, typically the most common scenarios involve three zones:

  1. The trusted (internal) zone
  2. The semi-trusted (dmz) zone
  3. The untrusted (external) zone

These three zones can apply to almost anything, from network based services, application programming and even physical security layouts.

The trick is separating zones in such a way so that we can maintain higher levels of security by protecting resources from zones of lesser security controls. The separation mechanism between zones could be as simple as a firewall, a piece of managed code or a locked door. The goal is to have some degree of control over what happens between the zones. And have logical communication medians to allow for zones to communicate safely where appropriate.

Theoretically it would be nice to live in isolation and never care about other zones. But in reality, at times some zones will need to be able to talk to others. If we didn't allow that, you wouldn't be allowed on the untrusted zone of the Internet from your trusted zone of your internal LAN. It would have to be severed. The trick is to understand the risks of exposure when communicating between zones, ensuring that some sort of filtering safeguard is working in between to determine what is, and more importantly what is NOT, allowed to communicate through the filter. As an example, there is a much higher level of risk in allowing a direct inbound connection from an untrusted zone to a trusted zone. This is why we have firewalls on our perimeters. (You DO have a firewall between the Internet and your computers don't you????) And the risks are significantly reduced if we place an untrusted inbound connection into a semi-trusted DMZ.

See how this all fits together? Zones give us the ability to reduce risk by applying technical safeguards in a logical manner through grouped resources. How we communicate between a trusted and semi-trusted zone would be different than an untrusted to trusted zone. And we can make better security decisions by understanding that.

I have been using a six-step process that Kevin showed me to apply the zoning concept into the decision-making process for infosec. The following procedures can help in that process:

  1. Identify any instance where an untrusted or less trusted object comes in contact with a trusted, valuable or more sensitive object.
  2. Determine the direction of communication that is needed. Ask yourself "Is it possible to use an outbound communication model (trusted going to less trusted), or do I need to have the untrusted object initiate the communication". Where possible ALWAYS try to have the more trusted zone control the communication.
  3. Determine where it would be possible to separate the trusted object into two components; one that handles sensitive information and the other that acts as a relay or middle entity in the transaction. This is why proxies can work so well in security.
  4. Determine what forms of communication need to take place between zones and block everything else. Understand the different levels of risk exposure and determine if its necessary to perform the tasks. As an example, why use clear text telnet if you can use secure shell (SSH)?
  5. Place as many security controls between each of the components as is reasonably possible, remembering what assets you are trying to protect. A $50,000 firewall doesn't make a lot of sense to protect your $500 collection of Michael Bolton MP3s.
  6. Document the reasoning, supporting data and conclusions in this decision-making process. Keep this document for reference and to simplify the decision-making process for similar situations in the future.

Create Chokepoints

Since the dawn of time, chokepoints have been a key part of security practices in warfare. A chokepoint is a tight area of control wherein all inbound and outbound access is forced to traverse. Kings of medieval times understood that if you could funnel the enemy through tight doorways it makes it much easier to pour down fiery oils on them. Likewise, its much easier to keep a thief out of your network when the network only has one gateway leading in and out. In the infosec space, chokepoints also grant us the advantages of:

  • Security focus - We can focus on particular areas of control.
  • Ease of monitoring - It is much easier to watch our enemies when there is only a few places to look
  • Ease of control - It is much easier to implement good security mechanisms when only dealing with a limited space
  • Cost reduction - By filtering access at chokepoints, we will only need to implement one control device at the chokepoint rather than having separate controls for every object. This reduces the time and materials required for the implementation and maintenance of security measures.
  • Exposure reduction - By focusing on just a few chokepoints of access, we introduce fewer opportunities for error and exposure than if we enforce security controls in multiple areas.

Chokepoints are a critical component of a higher security mind. They greatly reduce the infinite number of possible attacks that can take place, and thus are some of the best tools to use in information security.

One thing to consider when using chokepoints though. They also become single points of failure. As such, it is important to increase the availability measures taken in relation to the number of access points consolidated. As an example, if everyone has to go through a single point to access the Internet, it might make a lot of sense to ensure there is a level of redundancy at the chokepoint.

Applying chokepoints is pretty easy. Here are some simple steps when contemplating chokepoints:

  1. Identify all access points to a particular resources or related set of resources
  2. Consolidate all such access points through a single security object
  3. Enforce tight controls, monitoring and redundancy on that security object
  4. Establish a policy for future access points, stating that they must be filtered through an approved chokepoint
  5. Continue to test and scan for new access points that do not filter through a chokepoint.

Layered Security

I think Bruce Schneier said it best when he stated that "security is a process, not a product." When looking at security architecture, it is important to recognize that no single device is without flaws. Every significant application, server, router and firewall on the market today harbors some vulnerabilities. Additionally, most of these same resources have a good chance of being misconfigured, unmonitored or improperly maintained. On their own, each object will eventually become a weak link that would allow an attacker to get in. As such, layered defenses are crucial to repel intruders and ensure that any one weakness on its own will not let an attacker in (or out for that matter).

Layered security is a hot topic and I don't have to really go into great detail. But here are a few things you can do to apply layered security in your organization:

  1. Take an object and apply as much security directly on the object as is reasonably possible
  2. Consider the access points to the object and apply as much security between the subject and the object as is reasonably possible
  3. Consider all the object's dependencies, include the OS, third-party services etc and apply security to each. This should be performed for both the object itself and any security mechanisms protecting the object
  4. Make sure the object itself and anything guarding the object are monitored and generate access logs. If one object is compromised, secured logs should exist elsewhere on a secure device for forensic analysis
  5. NEVER consider an object safe simply because another object is protecting it. NEVER forgo directly applying security on the object assuming no one will ever be able to attack it

Understand Relational Security

Information security involves numerous chains and relationships. Any given object will almost always have a series of relationships with other networks, applications, events etc which will prove to be of great significance to our security considerations. The security of any object is dependant on the security of its related objects, and if we fail to see these relationships, we will be unable to properly address security. This is called relational security.

A server, for example, may be considered safe because it is not connected to the Internet. It is, however, accessible by the administrator's home computer through a dial-up session. The admin's system itself is connected to the Internet through a broadband connection. Thus, by following this chain of relationships, the server is actually connected to the Internet. Following such chains can point out where systems and networks that are considered to be safe are, in reality, vulnerable. And this is exactly how hackers typically gain access to systems. They go in through less secure back doors to gain access to more trusted systems.

Vulnerability inheritance is probably the most vital and yet most neglected security relationship. The level of vulnerability within any object should be considered in relation to the vulnerability of its related objects. A file share between a secure system and a vulnerable system greatly diminishes the security of the secure system. If the secure system is accessible in any way from the vulnerable system, then, to some degree, it will inherit those vulnerabilities.

This is exactly how modern worms breach sensitive systems. Which is why I think its NUTS to have things like nuclear power plants remotely accessable. When will we ever learn!!!

Understanding Secretless Security

The best security solutions are those that rely as little as possible on secrecy for protection. Relying on secrets for security has several weaknesses. For examples, secrets tend to leak out. If you keep your life savings under your mattress, and yet talk in your sleep... your secret may be easily compromised. Secrets can also be guessed. A thief breaking into your house may just look under your mattress during the burglary. If you magnify this problem by a few thousand end-users and several administrators, then you will probably spend more time securing your secrets than securing your valuables. Let's look at some classic examples where secretless security is commonly applied.

  • Open encryption algorithms - Cryptography history is riddled with the failures of encryption that used secrecy for protecting information. It wasn't until the most modern algorithms that used keys that secretless security came into play. Not that it's perfect mind you. Instead of worrying about keeping the algorithm secret, we typically have to still keep our keys secret. Which is why the focus of encryption of today is in protecting the keys... and not the code itself.
  • Open security applications - This is the old argument of black box vs crystal box security. You can read my article on Shattering the crystal and poking holes in the black box to understand what I mean about this. As has been proven time and time again, applications that base their security on a secret will eventually be discovered and the security will be rendered useless. Good security applications do not base their security on secrets.
  • Secretless authentication - With the dismal failure of secret-based solutions such as passwords over the years, many organizations are now turning to alternate approaches to safeguard authentication. Advanced authentication no longer bases itself on just what you know, but typically also include something you have and/or something you are. This is why two factor authentication is surging in the enterprise space right now. It is much easier, for example, to fake someone's password at an authentication prompt than it is to fake their eye pattern during a retinal scan.

Dividing Responsibilities

Have you ever heard the phrase "don't put all your eggs in one basket"? Never have all your investments in one industry; never rely on a single person to do a critical process; and never, never, assign all security responsibilities to one employee, one system, or one process. And, if you are a security professional, make sure you are never the one with all the responsibilities and power. (Even if you WANT to be a BOFH... don't)

Separating responsibilities does not stop with personnel, however. This concept applies just as strongly to placing all our faith in one security application, or one security device. If Server X is the only thing protecting our entire company, performing filtering, content management, intrusion detection and authentication, and running VPN and logging, we have a security issue. No system is perfect, and no security device is unbreakable. (No matter how many vendors claim their's is... even when offering rewards to hack it) At a minimum we should have something monitoring and protecting the security of our main security devices.

Here are some standard management practices you can take to divide responsibility within your organization:

  • Maintain redundant staff - Always have a designated backup employee who can take over another security employee's primary responsibilities. Rotate people through the positions so that they are not only familiar with the role, they can adapt and take on the responsibility later if the primary employee in that role leaves, gets sick or goes on vacation.
  • Monitor everyone equally - Ensure that any security measure applied to the organization is either universally enforced or has some equivalent security measure applied to the admin and security staff. If the security staff monitor everyone's access, make sure someone else is monitoring them. (Such as the admin group, and vice versa)
  • Enforce security rules on everyone equally - Everyone should be made aware of the rules and the fact that NO ONE is an exception. That includes the CEO... and the security staff.
  • Always follow layered security practices - By applying depth of security in your organization, when one thing fails external components assisting in security should know about it. Separating responsibility in this manner ensures that if a system is compromised, the logging and monitoring systems should know about it.

Failing Securely

If you read my personal blog at all, you know I typically talk about this when talking about designing secure software. It is more important to test the code execution paths when something fails, than when it succeeds. This same thinking should be applied to the higher security mindset.

Everything is subject to failure, no matter how robust or expensive it is. Such failures often lead to lost productivity and potential security issues. As such, potential failure scenarios should be considered before any new implementation. When programming an application, failures should be made to lock down security. When a network architecture is designed, failures should not result in bypassing security as is commonly done. It should fail "CLOSED" (to not give any access). If a power outage occurs, services, applications and devices should apply security during the reboot process. Consider failures in all devices and services, walk through the contingency plan, and consider the security implications therein. This is especially essential for major failure plans like disaster recovery policies.

I used t