• Logs = Accountability!

First up is Laura.

I have been a Security Program Manager for the last 3 years, working as a security advisor for a variety of products across Microsoft and the last seven months as a member of the SDL policy team.

 It's been a few years since I've been to TechEd, and this was my first time attending as a member of the security team. TechEd is now a two week conference, with one week dedicated to developers and  the other to IT professionals.  I think that breaking down the conference into a Developer week and an ITPro week was a good idea, and it allowed us to have good conversations with people who wanted more information about the SDL. I did two main things at TechEd:, I presented on threat modeling, and I spent a lot of time talking to customers at the SDL booth. At the SDL booth, we heard questions ranging from "What does the SDL stand for?" to "Our Web site was hacked; how do I stop it from happening again?" It was encouraging hearing people interested to hear more specifics about how we implement the SDL at Microsoft, and thinking through how they can apply it in their own companies.  My understanding from other TechEd veterans in our booth is that interest in the SDL seemed higher, which is great.

During my Threat Modeling session, , most of the feedback and follow-up questions were similar to the ones in the booth: how to expand the threat modeling processes to their own companies, and how to get started.

My typical response to both questions is to start small and do what makes sense for your organization. At  Microsoft, for example, when we introduce new SDL requirements, we usually start with a few teams so we can refine the requirement and supporting tools before expanding the requirements to a broader group. Similarly, while we have a core set of requirements that all teams have to meet, there are other requirements that are specific to a platform, scenario, or functionality. For example, there are some requirements that make sense for desktop-oriented products, but do not make sense for mobile devices.  You may very likely have to make changes to our policies to make them relevant to your organization, your scenarios, and functionality.

Now over to Michael.

Hi, Michael here.

One of the joys of presenting at TechEd each year is hearing from real people about the issues they face using our products in the real world; rarely are the issues pure philosophical security geekness. This year I gave two talks and one "chalk talk." The talks were "Top Ten Strategies
To Secure Your Code" and "How To Review Your Code
and Test For Security Bugs", and the chalk talk, which was a lot of fun, was simply answering numerous developer questions.

It's interesting to gauge overall security awareness from our customers, and there is no doubt that over the years, the level of security knowledge and maturity has risen. I think it's possible to evaluate overall security maturity by the questions posed. Some years ago, security was never really a topic of discussion other than those that relate to security technologies, such as how to use and manage X.509 certificates. About four years ago the tide really changed and people started asking more questions about "secure" application deployment and management, and developers wanted to learn more about securing their code; especially C and C++ code. Even then there was still a reliance on exterior defenses like firewalls. All too often I would hear people claim that they don't need to focus on securing their apps because a firewall was in the way. Heck, David and I documented this excuse in the original version of Writing Secure Code (Appendix D, "Lame Excuses We've Heard, #6, ‘We're Secure-we use a Firewall'") way back in 2002.

Fast forward to 2008.

Things have obviously changed. I don't know if finally the security message is getting through because many people asked me highly specific questions about securing their apps and how best to use the defenses we offer in Windows Vista and Windows Server 2008.

I still hear the firewall excuse a little, but not too much!

Perhaps the most telling trend I saw this year was a great deal of interest in the SDL. Not cursory, "that looks interesting" interest, but, "how can I implement this in my company" interest. After answering specific questions, I pointed most folks to  Jeremy's "Crawling Toward SDL" post on the subject.

In my opinion, getting to a point where you want to change your development process shows you really understand there's an issue that needs fixing.

Now, some people hate logging, because  logs are too hard to deal with (enable, collect, store and especially understand and interpret). However, there is a whole other group of fairly intelligent people who "hate logs:"   the organizers of some well-known technical security conferences. The experience of many of my colleagues (and competitors!) and myself proves that a log-related talk will NOT be accepted to ANY technical security conference nowadays. Now, some were generous enough to explain why. Others were not (screw them and no link :-)).

But let me rant about this one a bit. First, it is always a possibility that they dislike me not logs:-) -  this is easily disproved, however, since some of my colleagues had the same exact experience. Do they dislike vendors talking about logs? Nah, this isn't it either - most of my conference presentations had nothing to do with LogLogic, even though they are about logs. Some of my friends (and this blog readers) tried to suggest that an audience of such events "knows everything there is to know about logs." This is not true since - gasp!- nobody knows everything there is to know about logs: they hide way too many mysteries (with useful answers!) to discount them like that.  Another one I've heard is that "real hackers don't get logged -> logs are useless", which is also silly: this is true only if you take a very narrow view of logs (e.g. NIDS alerts),; clearly, everybody is logged by the firewalls, servers, apps, etc. The challenge is not a lack of data, but too much data and not enough time and tools.

But we are about to "hit paydirt" with this question...

Tool? Did I just mention tools? This opens the last and final, deeply evil reason for such "log-hate":  one of the conference organizers mentioned that, in his opinion, there is nothing new in the field of log analysis since regex-match-based alerting (and regex-based parsing into database tables).

And you know what?

Drum roll....

He was actually somewhat right.

Indexing did come in the world of logging, but, personally, I don't find it to be a huge feat of human ingenuity (even though it is definitely useful). I also think we are not doing enough with index data (and I definitely intend to change that...)

In addition, there was A LOT of academic research on the subject, from the SRI EMERALD in the 80s (and even earlier) to today, but many of the papers I've seen sit on the "hilarious side of useless"...

So, I need a campaign "Making Logs Sexy Again!" (and some impressive research results to boot) - will it work? Let's try and find out!

What is a log? A secret

Let’s crack it now!

Resist it will furiously

Saw these interesting quotes by John Thompson in this article by Ellen Messmer. 

On Cisco: "It shows Cisco would rather work with anyone other than Symantec. Cisco has a philosophical point of view that if you compete with me, you can't partner with me."  Amen to that John!

On McAfee: "It's a nice little company and they do a nice job. The industry needs competition." Ouch, that was mean!

On Microsoft entering security: "It's been much ado about nothing. Their results have been fairly abysmal .."

Seeing John this sharp leads me to believe me must be feeling the pressure over at Big Yellow.  And people say I am tough on my competitors!

Saw these interesting quotes by John Thompson in this article by Ellen Messmer. 

On Cisco: "It shows Cisco would rather work with anyone other than Symantec. Cisco has a philosophical point of view that if you compete with me, you can't partner with me."  Amen to that John!

On McAfee: "It's a nice little company and they do a nice job. The industry needs competition." Ouch, that was mean!

On Microsoft entering security: "It's been much ado about nothing. Their results have been fairly abysmal .."

Seeing John this sharp leads me to believe me must be feeling the pressure over at Big Yellow.  And people say I am tough on my competitors!

While all the innovative start-ups were working steadily on a new generation of security solutions, a majority of the industry’s big dogs jumped on the NACwagon, riding the buzzwords by simply re-branding a current technology as NAC.

And, that’s the culprit we’ll find if we dig to the root of our ‘Terminology Twists’ as I called them; a variety of words, definitions and catch-phrases from various NAC vendors that are incongruous with one another.

For the most part, our remote access vendors, switch and wireless vendors and firewall vendors (am I missing anyone?) all took their product, made a few cosmetic changes, a few verbiage updates and slapped a ‘NAC Sticker’ on the front.

Hence the Polymorphic Paradigm…  “a philosophical and theoretical framework”…  with multiple forms of a single product.

I suppose I’m fine with it… as long as it all works. But I would certainly prefer a world where we have some ‘truth in terminology’ so our customers can easily identify what products, technologies and features they’re actually getting. Until then- just check under the NAC Sticker and see what technology is behind it, and whether that will suit your needs (or not).

# # #

Scott commented that you can get cheap code-signing certs, as Jon Robbins points out. 80 bucks sounds like quite a deal, but a quick look at Jon's post reveals that a cheap code signing cert isn't as easy to use as one issued by the big dogs:

I had some trouble with registration process at Comodo. Make sure you add https://secure.comodo.net to the list of trusted sites in Internet Explorer so they can properly get you registered and install their trusted root certificate on your computer.

It's not just ease of use that I'm worried about here though. What's it mean to ask your customer to install a CA certificate into her trusted root store? I'm thinking of a nontechnical person like my mother - what's she going to think when she's asked to approve something that looks like this (the dialog that pops up on Windows XP when you try to install a cert into the trusted root store):

(click image to enlarge)

If you find that your customers tend to choose the default option here, "NO", your code signing cert won't be trusted, which begs the question, why didn't you save yourself the 80 bucks and simply issue your own code signing cert via Windows built-in Certificate Services?

And even worse, what does it mean if you find that your customers tend to choose, "YES"? That leads to the philosophical question: what use is PKI anyway if the end user doesn't understand it? If every software vendor creates one of those web pages (I'm sure you've seen them) instructing users on what to do when they see the above dialog ("press YES"), then ultimately what's the cost to the consumer?

I don't like tithing to my certificate authority any more than the next guy, but buying a "cheap" cert is more costly in the long term. If you need a cheap certificate for testing or for personal reasons, issue it yourself! If you need a real certificate, your best bet is to stick with a vendor that your customers already "trust", for better or for worse.

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.