To kick off our celebration of our first five years, we asked ScienceLogic founders Dave Link, Richard Chart and Chris Cordray for their thoughts and memories on events leading to today’s milestone. How and why did they set out on this venture? What happened along the way – expected and unexpected? Why were they successful in times when other new (and established) businesses have come and gone?

How did you three put together this team?

We all worked together at a large Managed Service Provider for a couple of years before leaving to start ScienceLogic, so we all knew each other and knew our collective strengths. More importantly, each of us had worked with network management tools on some level (sales and marketing, engineering and product development), and knew first-hand all of the customer pain points, from every perspective. So we left and began rapidly figuring out how to build a better network management solution based upon our real world operational experience..

Dave: One interesting aspect is that our areas of expertise don’t overlap, which has contributed to our success. Chris is excellent with developing the product front-end and interface, Richard handled the backend architecture and engineering and I focused on the technical business side of sales and marketing. Our roles have been to build a product that works well and that provides real value to operations teams that experience the same day to day frustrations that we felt.

Whose idea was it to start the company?

Dave: It was really a collective effort. We were all passionate about “getting it right” and not just starting a company. We knew the industry need and between us, we had the knowledge and skill sets to address all of the right aspects of developing a product and a building a business around it.

What process did you go through to get started?

Richard: From the beginning we knew the type of solution the market needed and we knew that we wanted to build it as an appliance. From different vantage points, we had each experienced the effects of long, difficult and expensive installations that still exist with traditional network tools. Every install has unique variations: there are always different server types, varying hardware and software versions, different patches installed, and on and on. Every installation was time consuming and unpredictable. We knew that an appliance model would address all of these variables and save a lot of time on how quickly customers could achieve immediate value.

The harder decisions were around actually starting the business, assessing the market and of course determining the product pricing.

EM7 completely flips the traditional model of complex, lengthy and expensive deployments. How did you convince others that the EM7 Meta-Appliance product was valid?

Dave: Yes, EM7 totally disrupts the traditional model for network management. While others take a narrow approach, we intentionally designed EM7 to focus on the broad problem – managing the data center. How do you cover a variety of technologies and make sure they work seamlessly together? The vision was to make it easier, not harder, for customers.

Chris: I have to give it to Dave – very early on, he realized the power of a demo. If Dave could get in front of someone, he’d make them a believer. He’d use the Peter Falk/Columbo technique of “let me show you one more thing.” It was very effective. It’s getting easier, but even today people sometimes have to see EM7 in action before they become believers.

Can you describe the early days of running a new business?

Dave: ScienceLogic is a classic case of entrepreneurship. For the first year we worked out of our basements. We kept the costs low in every conceivable way and spent the first year developing the product before we even made a sale.

Chris: We stayed at lots of odd places when we were on the road, took cheap flights with multiple layovers and purchased lots of our first test equipment on eBay. This was during the dot-com bust so there was lots of equipment for sale on eBay, really cheap!

Richard: The amount of equipment I had in my house was absolutely crazy. Back then, servers were huge – I had a Cisco 6509 Catalyst, a Compaq Proliant DL380, Brocade switch, IBM Netfinity 4500R, and tons of other machines.

Chris: I had to install a new circuit box at home because I was blowing breakers. I remember when that 6509 crashed, we revived it and it died again. The second death was final.

So you started in your houses – what was your first office space?

Dave: My friend, the CEO at Ernst & Young Technology had a few extra cubes and a data center in their office that they graciously allowed us to use. Their help was an important step in helping us really formalize the business. We started doing well and adding people, but ironically, their company was downsizing. Before long, many of their original YET people were gone and the ScienceLogic team kept growing in to the open cubes.

Our first leased space was converted warehouse space in Chantilly, VA that once housed an internet radio station. It was cool – it had a large salt water fish tank, a loft, a spiral staircase and a Star Trek door that retracted into the walls with the customary lights and “whooshing” sound.

We outgrew the Chantilly space, leading to our current office in Reston, VA.

Who was the first ScienceLogic customer?

Our first paying customer was Martins Point Health Care. We deployed there in July 2004 and are pleased to say they continue to be a ScienceLogic customer. Other early (and still) EM7 customers include Navy Knowledge Online and the Department of Transportation. Nearly all of our customers are still actively using EM7 and renewing their maintenance.

Where do you see the company in the next 5, 10 or 15 years?

Well, our revenue has doubled year-over-year in each of the last three years, so of course we’d like to continue to grow like that or even faster. In five years we’ve gone from three founders to the point where Dave does not know everyone’s fondest childhood memory. We’ll continue to scale our growth to cover the demands of our growing customer base.

Where do you see the industry going over the coming years?

Chris: IT is always moving and gaining in complexity, so network management is also becoming more complicated. There’s increasing diversity, new standards, virtualization and cloud computing. All of these are today’s technologies. Customers have a mix of the old and the new, so EM7 has to accommodate and support both.

Richard: Each generation of products has a new set of ways to monitor, but the “old” doesn’t go away. Even when a new, hot technology comes along, the old technologies still need to be supported. We work to ensure EM7 keeps up with both.

Dave: After five years we’re just hitting our stride and we’re just now reaching the tipping point in awareness of ScienceLogic and EM7. We’re all still passionate about the product and as Chris and Rich said, there’s still a lot do. We’ll continue disrupting the market with EM7. Our vision hasn’t changed, and with the increasing levels of automation that customers demand, the market needs are greater than ever. Our future is as bright, or brighter, than ever and we’ll continue to be looking for smart ways to automate traditionally manual IT Operations processes.

What’s your advice for someone interested in starting their own business?

Chris: Be passionate. That’s what has gotten me through the tough times. I didn’t really appreciate this thought when I heard others say it before. But it’s very true.

Richard: I agree. We met and talked with lots of people who told us, “That’s been done before.” But we kept going because we truly believed in what we were doing and we knew that while our approach was different, that it would be successful.

Richard: Be fearless. You can’t be too nervous and you need to be able to expect and handle the stress because it will be there. You have to learn to accept the stressful times as a necessary part of the process of starting out on your own.

Dave: Know your niche from the beginning and give potential customers a compelling reason to trust you and really benefit from your solution. You have to know the problem, see the gap and have a clear and consistent vision of how to solve the problem. Then you have to execute. If you don’t build your team with “doers” you won’t make it.

Chris: It helps to have friends. ScienceLogic was built on friendships and relationships, starting with the three of us. If you look at our team, most of our hires are referrals – people who developed and maintained great connections with other great people throughout their careers. Maintain your connections and keep in touch with your network of friends.

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned. It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned (here is a more accurate report). It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

The trick to doing this is not to hardcode things like host, port, etc. for your SMTP server when you use System.Net.Mail to send mail. Instead, use the default ctor for SmtpClient as I've done in the code below.

static void Main(string[] args)
{
    // note the use of the MailAddress class
    // this allows me to specify display names as well as email addresses
    MailAddress from = new MailAddress("admin@fabrikam.com", "Fabrikam Website");
    MailAddress to = new MailAddress("mari@fabrikam.com", "Mari Joyce");

    MailMessage msg = new MailMessage(from, to);
    msg.Subject  = "Testing 123";
    msg.Body = "This is only a test!";

    // note use of default ctor
    // this looks in config to figure out how to send mail
    new SmtpClient().Send(msg);
}

What you're telling .NET by using the default ctor for SmtpClient is, "please use my config file to figure out how to send mail". Now you can use the system.net/mailSettings/smtp section in config to specify the details of your mail server, and all of the code in your app that is written to use the default SmtpClient ctor will inherit these settings. Here's an example of what the config on a production server might look like (if you put passwords in your config files, be sure to encrypt those sections):

<configuration>
  <system.net>
    <mailSettings>
      <smtp deliveryMethod="Network">
        <network host="mail.fabrikam.com"
                 port="25"
                 userName="WebsiteMailAccount"
                 password="whatever"/>
      </smtp>
    </mailSettings>
  </system.net>
</configuration>

During development, I use different settings because I don't usually want to deal with the hassle of installing an SMTP server on my development box. Instead, I want email messages delivered as individual files in a directory on my hard drive (I always have a c:\mail directory on my development box for just this purpose):

<configuration>
  <system.net>
    <mailSettings>
      <smtp deliveryMethod="SpecifiedPickupDirectory">
        <specifiedPickupDirectory pickupDirectoryLocation="c:\mail"/>
      </smtp>
    </mailSettings>
  </system.net>
</configuration>

Now when I run the program above, I get a .EML file in my c:\mail directory:

Outlook Express is normally registered as the viewer for .EML files, so double-click the file to view it:

If you've never seen this method of simulating email before, I hope you find it as useful as I have. Happy coding!