(in)Security Architecture - Fred Baumhardt

All too often people are prepared to blame the wrong things when dealing with the painful area of security issues and compromises. They are embarrassing, costly, painful, and severely unpleasant experiences, and a culture of recrimination, and fault finding soon arises in our attempts to understand what happened, and why. My perspective on this is very clear, having done my share of post-mortems on customer site. The blame culture is unhelpful, and responsibility should be borne by several areas of the IT function; however a few people in the organisation seldom get caught up in security issues and in my view are amongst the most responsible. The security and the infrastructure architects!

When we have a security incident, the blame usually goes first to the vendor of the vulnerability in question, unless of course it was a configuration exploit, in which case the vendor also gets it for making it too easy to configure it incorrectly, or the engineers get blamed for a “sub-standard translation of the architectural vision into an implemented infrastructure”. Vendors are nice to blame as they are external to the org, and its not a  personal" attack.  Two areas seldom get blamed in the post-mortem. One, the firewalls or perimeter device which allowed the vulnerability to pass through it (because it is never the security devices fault for having weak security, the application gets blamed), and the other is the architect who masterminded an infrastructure which got hacked in the first place. Both of these points are controversial, and we’ll deal with dumb firewalls in another posting.

You’re an Architect – OK answer one skill testing question

My favourite question to ask to test the understanding of the security/infrastructure architects big picture awareness is to ask them about patching. The question usually goes like this – how do you feel about patching, and its importance and relevance to IT security? I would expect several different answers depending on the level of awareness, vision, and at what point in the infrastructure hierarchy and career the candidate is at.

The Build Technicians’ (Rack Monkey J ) View

 A newcomer to our industry who is working their way up the IT hierarchy, and is currently an entry level helpdesk engineer, or server build engineer would respond with something to the extent of: “ITS PAINFUL, TIMECONSUMING, and KILLS MY WEEKENDS, but its critical to our security”. This is an understandable position from someone who is on the front line of the vulnerability arms race, and quite justified from their viewpoint. He or she is paid to do that update management function, and suffers that pain. They dislike genetically the second Tuesday of every month, and know that Quarterly update cycles of their database products mean no weekend for them. Maybe to this level of experience anything to make the process faster would help, and tools like WSUS, Systems Center configurations manager, and/or other management tools would be the next step that should be taken, to reduce the time spent on such tasks. This is an entirely practical and acceptable position at this point in your career.

The Engineers View

With a few to several more years experience, product knowledge, and Technet sessions, the technician becomes an “engineer” with lots of exams passed, certifications, project experience, and product mastery. At this point Microsoft technical people tend to specialise in a given area of technology, for example messaging, DBA, or security, and start to question orders from above, made by people with a perceived incomplete understanding of the technology as opposed to theirs, but who they respect as more senior and “closer to the ”business”. To the engineer, they look at mitigation through layers of defence, the use of advanced security devices like IPS/IDS, central policy, audit, and integration of some cross product security features and infrastructures as the more relevant security platforms from which to build upon. They will for example, understand the role of ISA to protect Exchange, and see that there is a better way to do it than sticking a front-end in a DMZ.  Engineers will usually tell you that “group policy” is the best security tool that Microsoft has, and will look at advanced lockdown mechanisms, and best practice whitepapers, and translate them into security implementations.

Engineers will also apply their deep knowledge in the product areas of their expertise to lock down and secure the systems as much as possible and will lead design streams in projects that carry those tasks. To them, best practice analyzers, the automation of patch management (made possible through infrastructure standardisation, and update test process, etc), and best practice whitepapers are the main weapons in their arsenal. They would answer the question of patch management as a necessary evil, and point to several upcoming technologies that would help alleviate the exploits going forward, and they shouldn’t be too religious about platform, or vendor; understanding that all require updating, and the infrastructure should facilitate and empower that.  In short, their opinion is balanced, tempered by experience, and is trying to solve the problem at an engineering level. Entirely reasonable in this phase of their career.

And the Architect? First define what you mean by Architect....

After many more years of experience, and countless project meetings, (and increasingly less technology ones), the engineer should progress to become an “architect” which is a very misunderstood term.  Many companies use the word architect as designator of rank. For example, a higher form of engineer, or a higher rank of IT person (the pinnacle of a technical role for example). Usually they enhance the current job title by adding the word architect to it. For example, Architectural Consultant (a higher grade of consultant) or Architectural Technical Specialist (a higher rank pre-sales engineer grade in the same job family). In which case, the word architect loses its value, or its meaning. Like for example the word “senior” when applied to consultant, or specialist, Senior is meaningless, it is a simple modifier of the standard role definition of consultant. Maybe with loosely defined higher expectations, but largely the same class of role. These are the people who I consider “rank architects” meaning, a higher paid, form of a current consultant, or IT engineer role, but they aren’t true “architects” in the sense of the word it was meant by the industry. I was a solutions architect for my first IT job, man did I ever lie well at the interview !

In the real world it is impossible to promote a building landscape engineer to become an “architect”, no matter how good they are as a landscape engineer. Architects have different skills, different points of view, and are trained differently, it’s not  a rank. The studies required are different, and the qualifications are different. I would expect a rank “architect” to respond the same way as an engineer to the question of patch management, as they would answer on technology terms, though maybe less precisely as they did when they did technology for a living.  Architects in the real world are paid to transform ! To envision, and to create a structure or entity that doesn’t exist, and is fit for purpose, and breaks new ground. Barcelona (where the excellent IT Forum conference was just held) is an incredibly beautiful place, with the buildings (in my view) far outshining the Mediterranean. Its
architects constantly push the limits, and do better buildings, with more beauty and functionality than just simple designs would mandate. 

In IT, architects are supposed to be paid to envision the type of foundation required for an (infra)structure, and commission the engineers to work on the implementation of the vision into reality, and transform the infrastructure into what the business requires. They are intimately close to the business customer, and spend a large part of their time serving and communicating with them. This is a very different role, with a different point of view. I would expect such a position to tell me that patch management shouldn’t matter as much as it does today. Because the the system is built assuming failures or vulnerabilities in it, and that the entire structure of the design wouldn’t permit a configuration exploit to occur, because its caught in three other places (defence in depth in the best sense – not the “salesey buy my product because I can’t think of another reason” way). Just like architects in high tectonic risk zones assume earthquakes in their design, and don’t blame the manufacturer of the planet earth for rattling the ground every once in a while. We know the earth has tectonic vulnerabilities, and buildings defy gravity so there is an issue there. So we build a structure that takes this into consideration.

Demand More, and question the experts

For too long our IT Architects have neglected their transformational role, and responsibility. Either by choice, or by lack of organisational empowerment (most probable). They still deliver “engineer” level infrastructures and vision which assume the same 30-40 year old design principles that lead to specific structural security flaws. IPv4 is still the standard for networking, people still assume VLAN segmentation works, people still think DMZs are a good idea, they still expect patches to be a primary defence line (thus rendering them susceptible to zero day exploits), firewalls are still relatively dumb, and people still put encrypted traffic through security barriers without inspecting the payload, to name but a few.  Kevin Sangwell, one of Microsoft’s Infrastructure Architects says it brilliantly: “some architects are afraid of breaking new ground: we know this way works and we’re tight on time so we do it this way again and again.”

This questioning or envelope pushing doesn’t occur nearly enough in most IT infrastructures, where the IT architect hides behind seniority or lack of proximity to the day to day operations when there is a security issue. Or they blame the vendor for the issue, or the IPS for not having a signature, with the classic excuses heard in post mortems. Next time, ask your architects where their vision is for transformation ? Ask them why we are dependent on patching, when the human body isn’t ! Ask them what the plan is for the transformational technologies like IPv6, NA(P/C), IdM, Dynamic Systems, etc  that will secure the infrastructure holistically, rather than rely on the signatron 10,000 IPS which will keep the same architecture but just add an ever more clever tool to do some small part of a big thing. What are the client side countermeasures, and where was the code review of the application ?

Ask them where and how they used to have to patch when they were “technicians” all those years back, and when they tell you, “that was a long time ago”, and they didn’t use to have to patch, they will usually smile and say “times have changed” in a reminiscent  kind of way, answer back with: “then why hasn’t our architecture ?”

It’s high time we took collective responsibility for security, not just Microsoft as a vendor or the industry as a whole, but the administrators, designers, and architects of modern systems who consume the technologies produced by the industry.  We all know there are better ways to do things, and that times have changed. Vendors are working hard to set right design decisions proved wrong by history and to improve the security in their products, but we need to do the same in our deployments as well ! It’s time we work together to understand the new vision for holistic security, and architect it, design it, and implement it. I for one, believe that we will need all ranks of IT to do this, and architects should lead the charge, not hide behind legacy not enough time” / too high risk excuses.  It’s no good the major powers in the IT industry adopting, changing, and improving security if the features, and architectures enabled by them aren’t used or deployed by customers. Architects should lead that vision, its their job to, and I like reminding them of that once in a while J

fred@microsoft.com for comments

It is a well established fact that SSL means Supreme Security  for the buzzword driven IT Security world. It is one of the great misunderstood technologies, and most security companies have educated the user to believe that if they see a yellow lock on the browser window the communication is "secure" and hack proof, with a trusted party, and its OK to put your credit card details in. Nothing could actually be further from the truth, and phishermen are having a field day as a relatively naive user clicks on a link to https://secure.ebay-address-update.com and puts in their details. The browser vendors then go and verify the certificate, and find it actually does come from a recognised cert provider, is still valid, and hasn’t been published on a revocation list. Once that is all clear, the browser puts the little secure lock logo in the window and the user assumes the page is secure. No one has actually checked that the domain ebay-address-update.com belongs to a unlisted company in east bolorovia (or other obscure country), and the web site is served from a datacenter in Tonga, and has nothing to do with e-bay. Some cert providers do a semblance of checks, but they cant be held responsible for the INTENTION of the certificate requestor. Then someone has a big party at your expense.

Secondly SSL is a rather strange technology, it authenticates the server to the attacker, but not the attacker to the server. I have always liked this, if I want to attack a website, if I see a valid SSL cert, I know I am attacking the right target. That server has a certificate issued to it, that a third party is vouching for the domain identify of it. Never forget that the client (attacker) has to provide NOTHING in terms of who it is, or what its intentions are for an SSL Security Association to be formed. The reason people use SSL is for that very reason, there is no special software or change required to the client, and the client needs only to check the certificate is valid (which all browsers do for you). The encryption just kind of happens.

Now for the next technology VPN ! In the past it  has been a license to print money for some appliance vendors as companies rushed to externalise access to their infrastructure and applications. VPN's power lies in the fact that a company could give full IP access to its internal infrastructure (if it wanted to) to one of its stakeholders outside the firewall security perimeter. It has been one of those frequently used technologies that has made it into the vocabulary of almost all corporate employees, or at least anyone that has been issued with a computer knows what it is. Vendors tended to compete in the VPN space by a few different means, the first is the encryption strength of the tunnels they set up between the client and the server, so CheckCoat says my VPN is better than CiScreen because I do AES256 and they only do AES128, or they use something bad like 3DES. So far, I haven’t heard in the Internet wild too many cases of a full on VPN tunnel being broken in mid-stream (if you have, mail me), so this argument is largely the type of "I can kill you with a .50 calliber, and he can only kill you with a .45. Net result is you're still dead.

The next compete argument is about the factors of authentication, and the new emerging technologies. The industry for a while ran out of ways to sell simple VPN boxes so they evolved new technologies for you to buy new “next generation VPN solutions”. Fortunately, these technologies are quite cool, and most quite useful (30 year old thinking simple layer 4 firewall vendors still own the “I can sell you a 1963 Trabant” as state of the art award). Given that VPN appliances due to their cost, etc were considered easy money (look at the Beware the Firewall Salesman post for an explanation of margin), tons of entrants to the market flooded in, and the technology became commodity as salesmen in droves entered the market. Differentiation of your offering became important, as the technology matured from niche, to commodity. A few things emerged, and its helped strengthen VPN technology:

1.)                          Multiple Authentication Factors – Like Smart Card, SecureWhatever tokens, potentially the anatron biometric device, and whatever other widget to replace, or supplement the password and username.

2.)                          Quarantine, or end-point compliance, where the host is assumed to be sick, untrusted, and infected, and isn’t getting access to anything until it verifies its health and state. These have also by definition required smarter clients on the host that can check security policy, have the right corporate security agents like spyware, AV, IDS/IPS etc, and other useful stuff like host based firewalls, and baseline security scans etc. Some vendors sell the clients as an additional authentication barrier, that only those in possession of the client can VPN in, which can also be a good idea, just beware patch management of the client as a few VPN vendors have found out, attackers can find vulnerabilities in the VPN client code too ;)

All of this technology has resulted in a fairly secure external access strategy being technologically available, well established and supported in the industry, and largely fairly secure. VPN is definitely more secure than internal access of a network now where Ethernet still gives you a switch port and DHCP an  IP address in exchange for the relatively difficult task of plugging a network cable into a PC (NAP/NAC is still in its infancy and less than 0.5 % share). But the downside…..Cost. It is initially a high fixed cost to deploy VPNs, with the concentrators physical installation, authentication setup, integration to backend systems, etc costing money, and new client keyfobs, VPN licensing structure (usually per user), and user administration costs having a marginal cost as well. But so far companies have happily paid the price. They get a TRUSTED client, which they installed, that runs security checks, with multiple authentication factors, that has been visited by IT, and quarantined. In exchange for this cost, relatively low business risk. At Microsoft we use this type of solution, with quarantine, security agents onboard, smart cards, and a custom VPN client all ensuring corpnet access is well protected. In return for this, almost full access to corpnet is provided. Check out www.microsoft.com/itshowcase for some info on how we do it.

SSL has been the accepted "security" technology for lightweight access requiring no client footprint, and VPN was the "thick client" solution, that fully expects client modification and control. So what happens when even quarantine, and the cool VPN technologies are becoming hard to sell ? We take the two buzzwords together, and make a brand new product, and thus a brand new appliance – the SSL VPN ! Basically what this device is, is a reverse proxy web publishing device that gives you access to web pages, and recently terminal services emulation, so that you can do everything you could do on a VPN, but without the client setup, maintenance, and administration costs (straight from the marketing literature). All you need is an Internet café in the Philippines, and during your holiday you can come into the bank’s payment systems and authorize and issue that million pound payment. Brilliant ! you didn’t even need to change your floral print shirt. How do they sell you this stuff ? Well largely they tell you that they can download a little ActiveX style control to the browser and that magic 100Kb in size control can rid the client PC of every known piece of malware, key logger, and bot on it. At only 100Kb it’s a bargain. Most AntiVirus vendors still need 2-5 meg download of their signatures, and the spyware engines also about the same, plus a series of checks to run that work on all clients and all browsers ? How do you even install an Active X control on a browser that doesn’t support it, and doest let you install code ? How do they do it….  They don’t !

Some SSL VPNs have clever technology like holding your credentials in RAM so that you can access multiple applications by logging on just once to the device, and they re-present them for you. They also do cache cleaning, where you can rest safe knowing the control will try to delete the cache of what you have accessed, and all your data is now gone from the browser.

But its not all bad, they can provide useful security features like pre-authentication, where the SSL VPN will auth you before you get access to a back end resource (kills current worms, as they are anonymous), and some applications are currently provided by SSL only, so its not all bad, but lets call it an SSL reverse proxy not an SSL VPN – these little clientless devices requiring no pre-existing footprint will not, and can never be true VPN devices. The reason is very simple, at its very heart VPN technology is about allowing a trusted client to use a network, not a trusted user, the only check anything does of the users’ intention is a credential, nothing else, and definitely VPN is not about letting an untrusted client in.

SSL VPN is about untrusted clients that you have never touched before, and never will again, being temporarily cleaned. You have to decide if you think the vendor’s technology can do this, but I don’t think it can. The key thing to do is ignore the sales guys, and think a very basic question. Assuming my attacker controls the PC I will be using to access my network, is the application I am trying to externalise too valuable to be accessed by the attackers machine ? What is the cost of the credentials being lost through keylogging, how sensitive is the information displayed on the screen (for cameras or screen capturing software), and should Bill be authorising payments whilst he is on holiday ? What if corpWorm waits for 10 minutes after session opens to launch itself in my network ? If I would NOT allow this shifty guy hiding in the shadows of the room into our corporate datacenter, why would I allow his PC ?

At Microsoft, anything requiring sensitive access to our infrastructure has to be multi-factor and trusted client base, it’s a simple business risk decision for us. Which isn’t to say all SSL VPN is bad. After all ISA Server 2006 will include “SSL VPN like” capability, but we don’t usually call it that, it misses the point. For web apps that you want externalised, we can do it, and do it well. But don’t force your apps to fit the constraints of the appliance you just bought ! Think it through with a proper risk review of what you are trying to make available outside, and always assume the attacker has full control of the client PC and that all client side checks have been fooled. If its sensitive to your business, or the loss or theft of that data is extremely high impact for you, then SSL VPN is not the right thing for you to do. Like most things in security its about tradeoffs, cost, and risk mitigation.If the CisScreen or CheckCoat guy tells you it’s the next new thing, its usually because if he sells 20, he gets a plasma tv, and you get the 18^th appliance to your security portfolio….

Do you have any ideas as to the type of content that we should be delivering as part of the depth training programme. The remit for us this year is to make deep technical (non-sales) content similar to a TechEd or IT Forum style event. What would you like to see delivered ? How long should each session be, and what are the burning issues you want to know about ?

The other question is we are looking at running a debate series to talk (with other security leaders) about what issues are important to you. So what are the hard pressing issues affecting Security in the UK or in general that you would like to see debated ? Feel free to suggest something controversial

Mail me with comments fred at microsoft, or post them to the blog :)

The common criteria IT Security evaluation process is a powerful, useful, well thought out, and well organised system from a technical perspective. To a deep techie it means that there should be some level of assurance that a particular product can stand up to a serious degree of scrutiny, was developed relatively soundly, and has good secondary characteristics like access to its source code and design methodology. No one should ever try to detract from that. From my perspective, I was one of the annoying "field" guys that pushed our ISA Server product team to do this certification, and feel very glad that they did. It is a significant investment for a company to undertake a Common Criteria evaluation (just ask anyone who has ever gone through it) and at Microsoft, we certainly took this project seriously, and both ISA Server 2000(EAL2), and ISA 2004 (EAL 4+), as well as Windows 2000, and Windows 2003, and XP all have CC certifications, as does Exchange 2003 with SP1 (EAL 4+). Microsoft is proud of these certifications, and has devoted significant resources for us to work with these industry bodies to attain independent certifications.

The sceptics will point to the fact that Microsoft can get CC as proof the programme is bad, apparently they view this as an exclusive club that the "insecure" shouldn’t join - a good example of this is here, in Bruce Schneiers blog, he just asks the question, the comments in it speak for themselves - it is a great discussion to read.

So what’s wrong with this whole thing? Well like anything in the security business CC is often (and usually) used to establish that the product is "secure", and that using it will make you secure. The good salesman will point out regulatory or governmental regulations sometimes obliging the use of a CC programme device, and it is engrained in the consciousness of the security world that a CC sticker means buy the product, which was never the intention of the CC programme in the first place. The techies among us will instantly point out that security is about the thinking and quality of the deployment, and its architecture, not just the collection of stickers on its constituent parts. For us to understand why salespeople get away with it, we need to understand roughly how CC works.

So here goes - when you submit a common criteria evaluation you have to decide what level of assurance you want your product to be evaluated to, according to UK CESG the following definitions apply from EAL1 to EAL7(highest)- click here  . For commercial software, EAL 4 is the highest practical level of assurance, you can get EAL 7 as a commercial product - check out here for proof, but part of the EAL 5-7 evaluations means that commonly used and known algorithms or those that don’t pass stringent criteria can’t be used (like SSL, or other ones the "normal" world today cant live without). In addition the higher certifications also require a high degree of simplicity in the design ruling out most commercial software which is classified as "complex". So beware myth number one - sales guy says "my product is CC so sign here on the order form". You need to know what level of assurance was tested. (and a few more things too, read on)

The next one gets also wildly confused, and that is the concept of a "protection profile", and the concept of a "Security Target". A protection profile is a "group" in windows terms of features that does one logical thing, for example a "strict firewall" which contains several features or characteristics that constitute that definition, like stateful inspection, dropping unsolicited packets etc. The Common Criteria site has a list of their profiles, and what feaures are in each – access it here, my favourite is “waste bin management” J . A lot of vendors find it easy to take one or two protection profiles and submit their product for evaluation. So CheckCoat takes their CisScreen 10000 appliance and submits it for assurance level 4+ for “strict firewall” – which means the EAL4+ level and depth of analysis will be used to evaluate the 12 strict firewall features of the CisScreen 10000. ONLY THE FEATURES IN THE PROFILE (GROUP OF FEATURES) would then gain CC if passed. NO OTHER FEATURE, if you enabled a bunch of other things, some of which may be on by default in the product, then most likely the certification would also be invalidated, unless only the features evaluated in that group were used.

When I go into customers I find that around 80% of the Common Criteria stickers on the outside are usually invalidated by the configurations or deployment of the devices, usually for a good reason, because the device was next to useless in its evaluated form, if you see this in a device you are buying, it’s a strong signal the company is doing CC to keep up with the sales angle. Most CC discussions at a product company have to involve a cost/benefit analysis of how much revenue you would expect to get, versus the cost (significant) in time, money, and human capital to undergo the certification, cutting the security target short is a way to lessen this pain.

So beware and figure out what features are in your evaluated Security Target and what ones aren’t. Usually the boss just says CC is required, so you only look at stuff with CC – not realising its not a simple box to tick. This brings us to the concept of Security Target, which is a list of all the features that were evaluated for (whether or not they are part of a grouping of protection profiles). Simply put a Security Target is every single feature that the vendor included in the evaluation, and thus would be certified in the evaluation. Many new features aren’t part of an existing Protection profile, so the vendor says my new cool feature (let’s call it Outlook Web Access Protection) isn’t in any firewall protection profile, so I will include the feature anyway on its own. So if the sales guy says “ISA didn’t pass the firewall protection profile so its not a firewall” doesn’t mean to say it didn’t evaluate as a firewall, just that Microsoft chose to put in custom features (usually more than in the simple profile) that didn’t exist in a grouping. Like we did when we added Outlook Web Access Filtration, and our RPC filter into our Security Target, so if you use ISA for RPC protection its still CC, if you use almost any other firewall’s RPC filters (the few that have one) you would lose your CC. For a good document that we wrote on what is in ISA’s evaluation criteria you can check here . So before you buy a common criteria product you should do two things –

1 – Check how you will deploy the product – and ensure that the entire infrastructure is going to be secure, don’t assume that a CC sticker will mean instant security.

2 – Check here for the list of what level the product has been reviewed at, and WHAT FEATURES (security target) were reviewed. Open the documents for your product and read the public sheet of what the sec target was, and more importantly, what wasn’t in the evaluation.

Check out www.commoncriteriaportal.org as a great place to learn more

What do you think - leave your comments - Should Microsoft continue pursuing CC ? Do you think it adds value (I do)?, What other certifications should we strive for ?

We will be posting all of the slides from todays UK Security Summit to http://www.microsoft.com/uk/security/securitysummit06  over the next few days. When we get the content in its final form from the speakers we will update.

If you had any feedback on the event, please let us know

Today we had our UK Security Summit 2006. One of the themes that got much attention from the audience and discussion was one of root causes versus symptoms. I am a huge fan of fixing a problem at its root, rather than band-aiding it. But sometimes we in our industry tend to think in product terms, rather than security terms. One of my favorite examples is one of the Medicine of Pathogens and disease. According to Doctors external pathogens seem to have four things in common with the human organism.

1 - They are anonymous - that is, the Flu doesnt authenticate itself to the body, it comes in over the "air" and without a common trust context infects the body.

2 - They break rules - Most viral and bacterial pathogens break a simple rule of operation and behaviour of the body. For example they attack our nervous system, invade our bloodstream, and do things that are generally against the "day to day" of the body. We have secondary systems that detect for us these breaches, and in most cases defeat them once the body Immune System works out a way to kill it.

3 - They came in unsolicited (arguably STDs, and bloodstream infections could have been self-inflicted) - meaning they came in to the body without the body asking or consciously inviting the pathogen, though maybe the body engaged in a conscious action that facilitated it, the immune system usually had little to do with it.

4 - As per the first post - the body generally runs with "admin priviledges" - meaning, most of us can (and sometimes do) apply for a Darwin award and kill ourselves by driving off a cliff etc. However,  the vast majority of our security systems in the body dont reach our conscious level of thought, for example, the Killer T cells dont tell you they just killed a bacterial infection at the tip of your finger, or warn you there are germs under your finger nails - if they did it would be too much data to handle (our human organism, like MS gets attacked alot).

So what can we learn from this, as Security Architects?

1 - Authenticate content - if you are authenticated (which major bits of tissue in the body are) then you are far more likely to be well intentioned, and likely to be good (though this is getting increasingly tentative in our world). We experience this in organ transplants and rejection when the body recognises (by a mechanism we dont fully understand) that an organ didnt originate in this body, and attacks the transplant. Though it doesnt favour us in this case, this un-authenticated attack role of the immune system defeats a large percentage of attacks of virii etc that try to fool us into thinking they are part of us. I wish I knew how we did it in nature.

2 - Understand what the rules are, and dont put yourself in risk situations - if a buffer overflow in SMTP verify is 200 bytes of traffic, and the VRFY command is analysed at the network layer and anything larger than 75 bytes is dropped (by the firewall or switch), then no 200 byte overflow (even the unpatched ones) can pass. This is one of the biggest benefits of IPS technologies and Application Firewalls, and the major reason they make their dumb L4 cousins look bad. The body can tell by smell, and even taste if most food is off, and it sometimes even invokes a gag or vomit response. Network equipment and dynamic protection can help us too if we follow these examples. The body also fails to safe under almost all immune cases, there are few "unterminated buffers", and if someone shouts at you and swears, it usually doesnt case a buffer overflow in your auditory system which gives the attacker root of your body. Though some of us may disagree looking at former partners who told us what we wanted to hear  ;)

3 - Stop unsolicited packets - basic and stupidly simple. Dont process what you didnt ask for first (in client server environments), this is the simple beauty of the original Windows firewall iterations, they kill worms, as worms send unsolicited packets. The outbound filtering part of it wasnt necessary for anti-worm defence. In the human world if you see a gunfight in the street, the fight/flight response kicks in and hopefully, if you care about your skin's security perimeter you will run away. You dont worry about getting a new evolutionary suit of armor or grow scales, you run away- rendering you immune to the "cross-fire" type of vulnerability in the body. One thing is certain, if you get shot, you dont usually phone your mother and blame her for leaving you with a vulnerability of soft skin that bullets pass through.....

I found this whilst looking through colleagues blogs. http://blogs.technet.com/sanger   - a very comprehensive guide on the process and decision making that happens in large scale Microsoft events. Its written by the guy (Kevin Sangwell, an MS guy worh his weight in gold pressed latinum)who was in charge of content for IT Forum 2005.

We get so many questions about presentations, or what does it take to present, etc. So this blog is a great place to start. In EMEA - we usually have a web site that people can submit their session submissions for. But if you do want to do it, make it about the content - new ideas, that are solution focused (verus just product) are welcome, and get serious consideration. "Using Group Policy in AD for Windows 2000" just isn't new enough, or has already been done 20 times before, so that would be more difficult.

In the security tracks we look for sessions not just on the security specifics of products, but also product solution sets or architectural security sessions. We also feature security up and coming topics or product futures, but usually they will be done by Microsoft speakers. If you have any suggestion of the type of content you would like to see in EMEA events (Europe Middle East Africa) then let me know, I will pass your suggestions forward. fred at microsoft is the email address.

Recently at a customer I was very surprised when they showed the architecture team their new and uber cool security architecture design that 20 days of consulting (10 of which were free from the "reseller") gave them.

Slight Techy Bit - Skip if you dont care..

In short it had a few flaws, the SSL datastream which penetrated their outbound firewall, also invalidated their new pride and joy IDS which couldnt see the traffic inside the SSL - traffic was hitting the web server anonymously, and the application was using a rather open form of authentication back to the database which was putting all information open on the corporate network (and DMZ). The data input quality was being checked by large client side javascript applets, and didnt seem to be bounds checked at any other level. They also needed to buy a new certificate from a different provider because their provider wasnt in the trusted root of this appliance.

Upon some digging it transpired that the solution was put this way to work around some of the deficiencies of the "appliance" that the sales person was trying to sell. The "consultants" were people who when we met them, they confidently told us port 80 was the port used by ping ! and prior to being security consultants (new world terminology for salespeople) worked at the local garage selling cars(I'll let you guess whether they were new or used). A 1800 dollar ISA box would have done the same job, but the partner would never want to use it, even though from a technical perspective it was superior. From a techie's perspective, this is just plain wrong, but from a commercial perspective its very simple to understand. Its about 1 word - that drives the entire security business - a techie may think the answer is "security" - a sales person knows its MARGIN.

Technology, does it matter ?

A Linux or free firewall (theoretically free, but look atTotal Cost Ownership) may be a better technical solution, an ISA Server withs its EAL4+ and battery of Application Filters would be a great security solution (our only firewall at Microsoft - attacked millions of times per day - never breached - I am proud of that ), and at 1800 dollars is an absolute bargain, and that is exactly the reason a "security business" person wouldnt touch either MS or Linux solution. They would recommend CheckCoat CisScreen 10000 - security appliance extraordinaire. And it wouldnt have a thing to do with its features...

A Lucrative Business

Almost all of the security business is three tier disribution, Customer - sold to by a re-seller, who buys from a distributor, who buys from the vendor (CheckCoat)

Lets assume CheckCoat gives the reseller 35 points margin (35% off the retail price). In actual fact they dont - they give the distributor (middle man to you and I) 50% off the retail price, and the distributor passes from 10-35 percentage points to the reseller. Most of the disties job is to line up willing re-selling partners to sign up to their distribution programme, and commit to buying dozens, hundreds, whatever of CheckCoat appliances from the distributor,  the more they commit to selling, the more their margin is (or discount off of full retail price they get), so if you are a re-seller who signs up to sell 10,000 a year - you may even get 40% off the retail price - leaving 50% for CheckCoat, 10 for the Distie, and 40% for the company making the recommendation to the customer. If you say you will sell ten a year- the distributor may only give you a 10% discount on the full price meaning they keep 40- CheckCoat gets 50% and the recommender gets 10%. The distie also usually handles logistics, returns of faulty goods, some do support, add pre-sales help, training etc as part of their package- in my view re-sellers provide good value for money given what they do. The Re-seller usually does the end-user sale, implementation, day to day sales activity etc, which is why their "consultants" recommend the appliance solution, the distie usually supports their re-sellers as well

Case Study

So, the more you sell, the more discount off full price you get, and the more expensive the appliance is, the more money there is to go around. Currently appliances average around 10K USD. So lets see how much SnakeOil Security gets for selling a 4 appliance deal to FleecedCorp via MiddlePerson Inc:

4 Appliances at 10,000 USD each - 40,000 USD order done by SnakeOil Sec

CheckCoat gets 20,000 USD giving the distie (MiddlePersonInc) a 50% margin as part of their agreement.

Because SnakeOil Security is a "premium" re-seller to MiddlePerson inc (they do a lot of business through them), they get 35% discount on the order. So they bought 40K worth of kit and paid only 26,000 for it leaving them a wopping 14 K USD profit from the sales alone. MiddlePerson Inc bought the kit for 20K - and sold it for 26K so they make some good money too. On top of this, SnakeOil security sold 10 days of implementation services to the customer costing 1000 dollars per day - or 10K in total. Customer paid 50K USD - for something that some people put on the Internet for free (FW software) CheckCoat charges the channel 20K for, and money was taken by distributor and re-seller (and its services business). Thats the security business.

So back to our ISA or Linux competitor to CheckCoat-

How much do I get for the Linux box ? 100% of the price great !!!!- thats amazing margin, ohh but wait its 100% of zero - ohhh that sucks, not touching that then, no matter what the features are. And what about ISA - I get a normal 2-10% margin from Microsoft so 4 servers X 1800 USD == 7200 USD order, but I only get 2-10% margin so I get up to 720 dollars- what - only 720 dollars is that it ?? Thats not enough to fill the tank of my new Hummer (paid by CheckCoat bonus last year) so forget that not touching that product either. Dont care what it does. I know, I'll tell the customer Linux is not reliable and enterprise ready, and Microsoft is insecure, and their only option is CheckCoat..... 

Final Analysis

Many of the dominant players in our industry have become so because of commercial manouvering, channel margin, partnerships etc, and not because of technology (which has really very little to do with it). There is actually nothing wrong with this, its the way business has been for hundreds, thousands of years. But it may not necessarily benefit you if you are in the market for something new in security.  A good pre-sales consultant is not an ultra technical one (most deep techies are useless in the security business), it is one that can wrap a customer need around the constraints of their specific appliance platform they want to sell, and overcome simple objections. As end-users wake up to the commercial realities this will become more difficult, and the snakeoil salesmen will be driven away (my fervent hope), by increasingly technical discussions.

There is some very cool appliance technology out there, and security technology in general is getting rich and complex, but in the short/medium term ask your visiting sales people some commercial questions as well as the technical ones to establish their true intentions, like most things in life, there is far more than appears behind most appliance recommendations :) mail me at fred at microsoft for comments suggestions etc :)

We have today opened the last few registrations for the public to come to our security and executive issues summit 2006 - Feb 20th - Monday. In this event we have some great speakers from the UK Microsoft Security Community and from Microsoft Corporate. It can be accessed by the following link : http://www.microsoft.com/uk/securitysummit 

We will talk about malware, (de)perimeterisation, services and architecture thinking, and things to do to fix the root causes of issues

From what I see in law enforcement discussions it is that organised crime elements are now turning away from “hard crimes” like drugs, etc, and moving into “softer” light collar crimes. Articles on the web on 0 day exploits being sold on the web are good points. In some dark room we have a computer geek who likes black and grey screens with stuff like subnet masks as their passion. It is these people with their perimeter firewalls that we now relie upon to stop a criminal org bent on stealing 30M USD from Bank Corp, who do you think will win ? 

I think that we in our community need to start knowing and expecting these types of threats as the “really” evil world start figuring out real and present ways to make money from the fact that the IT world at large is in its IT security infancy, as opposed to the relatively mature physical security world we live in. Easier to “L8 a bank, than to mount a full bank robbery with guns and stuff “ is an example of this.

Personally, I expect to see a shift away from script kiddie worm attacks of badly constructed attack payloads, towards “designer attacks” crafted with a specific target or segment in mind in a relatively complex multi person operation with hard and fast commercial gain as the objective. Key to this will be the time and maturity of vendors and how long they take to patch, test and remediate their stuff. Some vendors, those that still dont acknowledge they have a "security problem" need to wake up to this reality. All software companies do, and Bill Gates has made this point with the TrustWorthy computing memo of 2001. What happens when there is a 0 day exploit in a platform that happens to run the majority of the world’s payment or financial custodial systems, and that vendor takes 20 days to test and patch, and remediate ?

 Un-ethical security researchers and vulnerability sellers are now a factor of production to the criminal element, not a criminal element in themselves. They are a new tool to use for the cons, fakes, extortion rackets, and organised criminals that use them. These will be the people that may get caught by the police whilst their bosses go free, like the low level criminals peddling whatever illegal on the streets. If we see this analogy through, the security community needs to do a better job in protecting customers with architectural security features that dont care about specific vulnerabilities and start assuming there will always be vulnerabilities. An IT System without OS, or application vulnerabilities isnt the security holy grail to my customers - after all there could be mis-configuration, bad design, and a variety of other factors that would be "hacked", not just an OS or App 'sploit. In my view a better goal is a well architected system that though is composed of potentially vulnerable systems individually, when aggregated as a whole, collectively isnt exploitable. The answer to this isnt an appliance or any other quick band-aid fix, its thinking, design work, and careful study of what is possible, and fixing root causes as opposed to symptoms.

Never forget the security "industry" mostly exists to sell stuff(services, subscriptions, etc), not to secure you, security is the product that is sold, it isnt in the best interests of a product vendor that does security only to secure itself out of a job. Its the job of a good security architect to implement solutions that dont just have the word "security" in them.  Most likely they, if well implemented, can do more than super-mega-firewall 2000 could ever do.

I have been challenged whilst working at Microsoft to up my thinking about security, architecture, and infrastructure. When I joined (around 5 years ago) I thought like a lot of IT Pros that I knew a relatively good amount about Windows and Microsoft did stupid things that I never gave it the benefit of the doubt for. Once you get to learn the reason behind some of the decisions made, you quickly realise very little happens by accident, and most things are done for a very good reason.

One of my favorite debates in this thread is the externally filtering firewall. (Outbound Filtering, Egress Filtering, whatever you want to call it). This is a relatively good technology that has its place, but the industry "experts" seem to entirely miss the point - One of the strongest features of a firewall for a client is in the area of worm defence - meaning that the kind of attacks seen like Sober, Slammer, etc that propagated themselves automatically would be impeded by a host based firewall. There is a usability paradigm to look at, but medicine teaches us that the most effective countermeasures are extremely simple and operate with no exceptions or conscious user interaction (like the skin, its stops bugs that would kill the heart - but doesnt let it pass through so heart is effectively immune), or are very complex and operate with little user interaction (like the immune system - which although it runs as "admin" on the body, doesnt really give you a choice).

Case Against it

Outbound firewall needs some work - in order not to kill the user with decisions and questions like "RPC End Point Query needs to speak to DC1 on remote 135 - do I allow" ? And inbound traffic is the most effective way to prevent a worm in the first place - if we look at an inbound blocking mechanism like a host based ingress firewall then it could stop a worm in several ways - the most important would be to not process the infection packet as you didnt ask for it. The argument from anti-outbound community says if you already have been infected its too late - and attack coders would have written some code in their pathogen to disable outbound blocking (if you accept this as a trivial action, which I dont)

How do you manage outbound connections and policy on 120,000 clients with outbound policy ? In XP Firewall and Vista we use Active Directory, and our firewall is fully scriptable, but it is a fair question, if you do want to manage a complex outbound filtering policy in a worldwide org, it wont be a small effort.

Trial posting - as is and confers no rights

Case For It -

Lets take an example from medicine (again) – when a host gets infected with a disease – we sometimes treat the disease from an epidemiological perspective by blocking its propagation to other hosts, and allowing the infection to run its course. Many diseases today, for which science has no answer for have this as our only defence. Quarantines, as well as more traditional barrier mechanisms all have a place in the real world. An outbound firewall if you could implement it correctly could contain an infection on a host to the host, and prevent it from propagating.

If you believe the above, doesn’t that mean that if correctly implemented, an outbound firewall can add real value? And if so, isn’t the question to ask “what is the kind of technology we have to engineer to make this a real barrier” Man has seldom seen nature get it wrong, ignoring post infection containment blocking strategies may be a cost benefit argument, maybe other things are cheaper or easier to do, but I would love for us to get this feature right. What would it need to do to be useful and legitimate from your view ? - mail me - email address is the same as my first name. at Microsoft.