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.

Collaboration in the Cloud

Forward thinking companies use collaboration technologies to melt away the physical distance between disparate offices, remote workers and suppliers.  Investments in R&D projects to create the next generation of business collaboration technologies and starting to bear early fruits and are worth paying attention to - especially if you get paid to “do security”.  One major focus area is Virtual Worlds.

Teleporting Virgins

The big news in the Second Life research community is that avatars (”virtual people”) have successfully teleported between distinct virtual worlds.  The virgin teleporters went from a Second Life Preview Grid - an experimental grid completely disconnected from the Main Grid - to a virtual world running IBM OpenSIM.

At this stage there is intentionally no asset transfer going on at all - in other words, you can’t take your “stuff” from one world to another - but that will come in time as the Open Grid Protocol is extended.  Today just login and teleport are supported.  No stealing those trade secret “assets” yet ;-).

Linden Labs speaks to this issue:

Q: How will Linden Lab prevent property from being copied into other virtual worlds?
We’re paying extremely close attention to that question. We will be designing this with the Second Life community to ensure their needs are met. We want to stress that when it does become possible to move avatars between worlds, we will take the utmost care to protect the rights of Second Life property owners and creators. Linden Lab will not design a system that lets people openly violate the permissions of SL goods and take them to other worlds. We recognize that intellectual property is the engine that drives Second Life, and we are completely committed to preserving the qualities that make Second Life the unique, innovative and dynamic place that it is today.

With my “hacker-vision” ™ enabled I see *all kinds* of opportunities for mischief here.  I’m betting we’ll see imaginative attacks as the usual cat and mouse game of vulnerability research and vendor response plays out.  “Sorry boss, someone hijacked my avatar and now I’m stuck on this desert island for who knows how long!”.

Threat Profiling Second Life

Getting back to reality, people are already exploring Virtual World security.  Michael Thumann of ERNW in Germany is a pen-tester and security researcher and in this 10 minute video, Michael shares the result of his security research on Second Life.

He covers:

• In-game cheating
• Identity theft
• Attacking 3rd party servers using Linden Scripting Language (think about the liability issues and the providers ability to track abusers)

For those interested in more detail, the full presentation he gave at BlackHat Europe 2008 in Amsterdam is here (pdf).

Of particular note, Michael applied a formal threat model approach to the research - STRIDE from Microsoft.

In a future post I’ll talk more about threat profiling in the context of Cloud Computing vulnerability research and specific API security vulnerability classes we can expect to see exploited.

Breach Disclosure Laws

Sometimes organizations lose control of data that’s been entrusted to them. You might find that risk as an instance of “information disclosure by external entity.” So should we have a check there? Well, on the one hand, we don’t have any control over it - unless we hand them that information by design. In which case, perhaps we could design to hand over less.  At Microsoft, we haven't added it to the chart we ask people to use, and we'll revisit that over time.

Specific Elements

Another thing you might note is that the STRIDE chart is sorta vague. A process could be an exe, a .NET assembly, or an a.out executable running on Unix v7. Each of those will be vulnerable to different instantiations of threats. Your exe or a.out will be vulnerable to simple stack smashing overflows, but the .NET assembly won’t be. As you make your elements more specific, you can provide more prescriptive guidance as to what threats to look for, and how to effectively mitigate them.

Customizing the Chart for Your Threats

The chart is centered on our needs at Microsoft. Those may not be your needs. Perhaps you’re building a threat modeling process to focus on voting. You can get much more specific about what a process is, and what threats it might come under. You might have really specific threats against voter lists (a type of data store) or vote tallies (another store).

Being able to enumerate the assets in data stores helps you motivate threats, and assess their risk and importance of fixing them. When we build a threat modeling process for the SDL, it gets used in Windows, Office, SQL, Exchange, Dynamics, and a slew of other products. We need some degree of consistency, so we can deliver consistent products and messages to our customers. We also need to encourage customization and specificity, so that the process is as prescriptive as we can make it. Doing so allows you to make it more prescriptive, appropriate and evocative for your users.

The brainstorming meeting is a mainstay of expert threat modeling. It’s pretty simple: you put your security experts in a room with system diagrams and a whiteboard. Usually, you put your system designers in there, and make them promise not to strangle your experts. Optionally, you can add beer or scotch. Sometime later, you get a list of threats. How long depends on how big the system is, how well its requirements are documented, and how well your experts work together.

We like having our developers threat model. There are a lot of reasons for this. Not only do they know the system better than anyone else, but getting people involved in a process helps ensure that they buy into it.

Now this desire is great, but it leads to some issues, first and foremost is that many of the people who are now involved aren’t security experts. This means that they lack both direct experience of the process and the background that informs it. This isn’t a slam on them. I lack experience in the database design process, and I don’t have years of experience to help orient me. So I’d make mistakes designing a database, and someone who isn’t a security expert may make mistakes in security. For example, someone might try to use encryption to mitigate tampering threats. (The SDL crypto requirements cover this, and I try to gently correct them to integrity mechanisms like MACs or signatures.) This is a reality that we have to account for at the process design level.

Adding Structure to Chaos

So how does this relate to the brainstorming meeting? It’s a dramatic increase in the need for structure. Where experts may think they do better threat modeling with scotch in hand, , it certainly doesn’t lead to beginners having a flow experience. So we need a structure, and we need to provide it.

We encourage people to get started by drawing a whiteboard diagram. Almost everyone in software draws on whiteboards regularly, and this makes it an ideal first step. It’s an ideal first step because everyone can do it, see that they’ve done it, and feel like they’re making progress.

The core mechanism we’ve used to provide it is the STRIDE/element chart. (I’ll talk a lot more about its origins and limits in a few posts, but for now, let’s pretend it’s gospel, and enumerates all possible threats.) Given this gospel, it becomes possible to step through the threat modeling diagram, “turn the crank,” and have threats come out. “Item 7 is a data flow? Let’s look for T,I and D.” (Tampering, Information disclosure, and Denial of service.)

Similarly, we have four ways of addressing threats – redesign, standard mitigations, new mitigations, and risk acceptance. We have training on mitigating threats, we have explanation of why and when to use each (and they’re presented in a preferred order).

Lastly, we provide advice about how to validate the threat model and it’s relation to reality.

Between these four steps and the hamster wheel which ties them together, we give people the structure in which they can take on the process. The other thing I wanted to address is how we respond to consistent “errors” that we see.

Where Trust Boundaries Show Up

We used to give people clear guidance that trust boundaries should only intersect with data flows. After all, you can’t really have a process that’s half-running as admin, and half as a normal user. Logically, you have two entities. And people kept drawing trust boundaries across processes and data stores. It drove me up the wall. It was wrong.

As people kept doing it, I decided to swallow my pride and accept it. I now tell people to put their trust boundaries wherever they believe one exists. And they’ve continued exactly as before, but I’m a lot happier, because I’ve found a way to help them draw more detailed diagrams where they need them. Which includes anywhere a trust boundary crosses a process or data store. They’re happier too. No one is telling them that they’re wrong.

I was going to title this post “Lord grant me the strength to change the things I can, the courage to accept what I can’t, and the wisdom to know the difference,” but, first, it’s too long, and second, if we started that way, it would be wrong to add beer or scotch.

One of the largest changes that we’ve made is to a simplified process (and diagram). I like to say that this looks pretty much like every other software process diagram you see today. That’s intentional. There’s only so much we can expect people to take away from a class, and making this simple and familiar helps ensure there’s room for the other important parts.

First, the “process hamster wheel,” (with apologies to Yankee Group analyst Andy Jaquith):

Now that you’ve seen the wheel, I’ll briefly describe the steps:

1. Vision: Consider your security requirements, scenarios and use cases to help frame your threat modeling. What are the security aspects of your scenarios? What do your personas expect or hope doesn’t happen? What are the security goals of the system you’re building, and how do those interact with the system as it stands?
2. Model: The basic idea is to create a diagram of your software, showing all trust boundaries.

a. Draw a diagram of your software. We encourage use of the DFD formalisms, which Larry Osterman describes in this post.

 

Essentially, the elements are

1. External entities (anything outside your control)
2. Processes (running code)
3. Data stores (files, registry entries, shared memory, databases)
4. Data flows (which connect all the other elements)

b. Draw trust boundaries between components. You can do this on a whiteboard, in Visio, or in one of the specialized threat modeling tools we’ve built. (A trust boundary is anywhere that more than one principal can access an object, such as a file or process.)

c. If your trust boundary crosses something which isn’t a data flow, you need to break it into two logical elements, or draw a sub-diagram with more details. (This is different advice: we used to tell people trust boundaries could only cross data flows. People drew them anywhere that felt right. We decided to go with what people were doing—there was important information in what they were expressing.)

d. If you need more details to express where trust boundaries are, add an additional diagram.

e. When you don’t have any more trust boundaries to draw, you’re done.

f. If a diagram doesn’t have any trust boundaries, you may have drawn too many details.

3. Identify Threats using STRIDE/element

For each element in your diagram, consider threats of the types indicated in this chart. (We’ll come back to the chart’s origins in a later post.)

There’s an important mis-conception we often see, which is that STRIDE is appropriate for use as a classification system. It’s really hard to use STRIDE to describe attacks—the impacts blend together really quickly. The most valuable use of STRIDE is to help people think about how threats have impacted elements of a design in the past. That is, it’s a framework for finding threats, not for describing them. “What if someone spoofs this host?”

 

4. Mitigate

Here on the SDL strategy team, we love threat modeling. We know that not everyone feels that way, and we ask teams to threat model so that they can find and mitigate threats. A threat model document with great diagrams and lots of threats isn’t very useful if you don’t take the key step of addressing the issues you find. There are four ways to do that:

a. Redesign to eliminate threats.

b. Use standard mitigations, such as those provided by OS features, to mitigate threats.

c. Invent new mitigations, understanding that this is a subtle art.

d. Accept risk, when allowed by the SDL

5.  Validate

There are two levels of validation. The first is within each stage, the second is a validation pass at the end of the process. That end of process validation entails:

a. Make sure that the diagrams are up-to-date and accurate

b. Ensure that you have STRIDE threats per data flow that crosses a trust boundary, and for each element that such a trust boundary connects to

c. Make sure you’re mitigating each threat

i. You have a bug filed per threat that you want to mitigate. The bug should be of the form “attacker can do X. Proposed fix: Y.” You might include tradeoffs you’re making, and possibly have test plans in the bug, if you include those.

ii. You have a valid reason for each non-mitigated threat not being mitigated.

iii. All threats are in class i or ii.

5.a. On change, re-validate

 

This hamster wheel has a very intentional brake on it: the word change, above validate. What that means is you want to go through the process again when you make changes that need to be on the diagram. Checking to see if your diagrams change is a relatively simple check that allows people to track changes against their threat model as their design iterates.

In the next post, I’ll talk about the reasoning behind the design, and offer up some process tools that anyone can use to make a process more user-friendly.

I've been meaning to talk more about what I actually do, which is help the teams within Microsoft who are threat modeling (for our boxed software) to do their jobs better.  Better means faster, cheaper or more effectively.  There are good reasons to optimize for different points on that spectrum (of better/faster/cheaper) at different times in different products.   One of the things that I've learned is that we ask a lot of developers, testers, and PMs here.  They all have some exposure to security, but terms that I've been using for years are often new to them.

Larry Osterman is a longtime MS veteran, currently working in Windows audio.  He's been a threat modeling advocate for years, and has been blogging a lot about our new processes, and describes in great detail the STRIDE per element process.   His recent posts are "Threat Modeling, Once Again," "Threat modeling again. Drawing the diagram," "Threat Modeling Again: STRIDE," "Threat modeling again, STRIDE mitigations," "Threat modeling again, what does STRIDE have to do with threat modeling," "Threat modeling again, STRIDE per element," "Threat modeling again, threat modeling playsound."

I wanted to chime in and offer up this handy chart that we use.  It's part of how we teach people to go from a diagram to a set of threats.  We used to ask them to brainstorm, and have discovered that that works a lot better with some structure.

Property	Threat	Definition	Example
Authentication	Spoofing	Impersonating something or someone else.	Pretending to be any of billg, microsoft.com or ntdll.dll
Integrity	Tampering	Modifying data or code	Modifying a DLL on disk or DVD, or a packet as it traverses the LAN.
Non-repudiation	Repudiation	Claiming to have not performed an action.	“I didn’t send that email,” “I didn’t modify that file,” “I certainly didn’t visit that web site, dear!”
Confidentiality	Information Disclosure	Exposing information to someone not authorized to see it	Allowing someone to read the Windows source code; publishing a list of customers to a web site.
Availability	Denial of Service	Deny or degrade service to users	Crashing Windows or a web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole.
Authorization	Elevation of Privilege	Gain capabilities without proper authorization	Allowing a remote internet user to run commands is the classic example, but going from a limited user to admin is also EoP.

[Update: fixed the table so it displays all four columns.]