CloudSec

Understanding Service Credits under 99.9% Service Level Agreements (SLA)

2008-11-28T01:44:00Z

The new Microsoft Online services represent an excellent option for businesses to base all or part of their Exchange, Sharepoint and MeetingPlace functionality within a Microsoft hosted data center.

But what about Service Level agreements for these services. What happens, for instance, if the service goes down for 2 hours in the middle of the day?

The following documents:

Microsoft Exchange Online Service Level Agreement

Microsoft Sharepoint Online Service Level Agreement

Microsoft Office LiveMeeting Service Level Agreement

are all quite similar and outline the Service Levels guaranteed by Microsoft for availablity, but with some important conditions and exclusions which need to be understood.

For instance, Microsoft offers "Service Credits" if the service is not available for a certain amount of time. These credits are based on the following table:

Monthly Uptime Percentage	Service Credit
< 99.9%	25%
< 99%	50%
< 95%	100%

At first glance, it looks as if almost any disruption in service would result in a refund from Microsoft. In calculating "Monthly Uptime Percentage" however, Microsoft uses the following formula:

TM = Total Number of Minutes in a Month

TU = Total Number of Users

Monthly Uptime Percentage = (TM*TU-Total minutes of downtime for all users in the month)/ (TM*TU)

As a result, if I have 40 users in my organization, and one of them experiences some kind of outage for 2 hours in December, the Total Uptime Percentage would be calculated as follows:

Total Uptime Percentage = (44640*40-120)/(44640*40) = 0.99993279569892473118279569892473

As a result, a Service Credit would not apply.

If, however, all 40 of those same employees experienced outages for 2 days during the same time period, the Total Uptime Percentage would be

Total Uptime Percentage = ((44640*40)-(2880*40))/(44640*40)=0.93548387096774193548387096774194

At first glance, it would seem as if a 100% Service Credit was due, however a careful look at the SLA shows other caveats. First, the SLA does not apply to any performance or availability issues:

Due to factors outside Microsoft reasonable control
That resulted from Customer's or third party hardware or software
That resulted from actions or inactions of Customer or third parties
Caused by Customer's user of the Service after Microsoft advised Customer to modify its use of the Service, if Customer did not modified its use ad advised
During beta and trial services (as determined by Microsoft)

and finally,Service Credits are only provided if the customer has submitted an incident to Microsoft support services and filed a special claim for credit within 5 days of the initial incident.

SDL Trickle Down Theory

2008-04-28T21:34:00Z

I just read a new article over in CSO-Online about our VP of Trustworthy Computing at Microsoft, Scott Charney.

In it, they refer to him as the "Axe Man" and his ability to stop products from rolling out due to security concerns

Since Charney joined Microsoft, on five occasions vice presidents in charge of products have disagreed with his no-ship order, Charney said recently to a group of reporters at Microsoft's headquarters in Redmond, Washington. Craig Mundie, chief research and strategy officer at Microsoft, was called to settle the disputes, and each time he sustained Charney's no-ship order.

I think the article unfairly characterizes Scott as an "AxeMan", as there are a large number of people and processes at Microsoft that can hold up, delay, or even cause a project to be canceled.

What is important about the article, however, is its exemplification on the critical need to have management understanding, sponsorship and backing of the SDL if it is to succeed. For instance, what if Scott didn't have Craig's backing in the disagreements described above? There is a good chance that the product managers might have pushed forward, and the SDL wouldn't have been worth the paper it was printed on.

In many organizations I visit to talk about Threat Modeling and the SDL, I find myself speaking to software project managers, or, even technical developers and sys admins!. While this is great, it's the wrong audience. The foundation for successfully implementing SDL in any organization has to start with executive management, and their promise to support a hold-up of a roll-out if certain types if security problems are found with a product (see appendix N of the Microsoft SDL for tips on establishing a "bug bar" which can help with this)

Too often, I see the SDL being talked about in terms of a technical process, for developers and testers. As with any initiative, without executive backing, chances for success are low. The SDL has to start with management sponsorship and backing and then 'trickle down" to project managers, developers, testers and admins if it is to succeed.

US Senate introduces strong privacy bill - YOU are accountable

2007-02-08T18:49:00Z

This bill was introduced last year, and is making the rounds again. Some of the wording that IT Management might want to read very carefully, centers on their accountability when certain data breaches occur:

Key features of the bipartisan legislation include increasing criminal penalties for identity theft involving electronic personal data and making it a crime to intentionally or willfully conceal a security breach involving personal data, giving individuals access to, and the opportunity to correct, any personal information held by commercial data brokers, requiring entities that maintain personal data to establish internal policies that protect the personal data of Americans, requiring entities that maintain personal data to give notice to individuals and law enforcement when they experience a breach involving sensitive personal data ...

Are you an IT Manager?

Do you have a defined set of policies in place that define how you are "protecting" personal data? If so, how are you sharing that with your organization.

Do you have a documented security incident response plan in place if a problem occurs? How will you communicate with your customers? Do you know if corporate council would be needed to help put together such a communique?

In many of the companies I have visited, the answer to these and other questions is "sort of".

Corporations (large and small) who deal with personal data, need to take steps to firmly establlish these types of policies, procedures and guidelines throughout their orgranization.

New Threat Analysis and Modeling (TAM) 2.1 tool released

2006-12-01T17:03:00Z

Containing many bug fixes and some enhancements, this is a great tool for organizations who may not have dedicated teams of security analysts, but want to model their application and automatically generate many of the possible threats.

The following are some of the improvements and features.

Improvements/Fixes
- Better Data validation (Tool identifies duplicate items, call and use case validation)
- Improved Copy Paste and Drag and Drop functionality
- Improved Analytic and Report Saving
- Improved Flow Diagrams
- Improved Visual Studio Team Systems Work Items export
- Improved Wizard Experience
- Threat Tree Visio export fixed
- Items found using the “Find Items” dialog can be cleared now
- Context aware Context Menu
- Improved Risk Measurement Plug-in Framework for Security
- Other bug fixes

New Features
- Auto Save Feature: saves the threat model automatically after specified number of minutes
- List Editor UI (no need to manually edit XML anymore for lists)

Mono not mentioned in Novell WebCast - but it is in the FAQ

2006-11-03T15:04:00Z

As a developer, the first thing I thought about with the Novell announcement was Mono and whether or not Microsoft would be putting resources toward that Herculean effort.

Miguel makes reference to the FAQ which talks about this subject:

Q: What does the patent agreement cover with regard to Mono and OpenOffice?
Yes, under the patent agreement, customers will receive coverage for Mono, Samba, and OpenOffice as well as .NET and Windows Server. All of these technologies will be improved upon during the five years of the agreement and there are some limits on the coverage that would be provided for future technologies added to these offerings. The collaboration framework we have put in place allows us to work on complex subjects such as this where intellectual property and innovation are important parts of the conversation.

I'm not in a position at Microsoft to officially comment on what "improved" from the FAQ means, or what role Microsoft will play in Mono development - but the developer in me sure gets excited about the prospect.

Imagine developing .NET 3.0 Web Services that could be deployed to both platforms! That would be interesting.

Even if we don't work on Mono, they did mention during the press conference that our two companies would be collaorating on interoporability between Active Directory and their directory services product (E-Directory?).

This could be good news for the adoption of WS-Federation, SAML, INFOCARD, et al.

Should we say goodbye to SecureString?

2006-10-27T15:17:00Z

Dominick over at Least Privilege makes reference to the new functionality added to HawkEye which allows developers to display the contents of SecureString, and also change the current principal of the running thread. This looks like a really great debugging tool, and I'm thinking about paying the licensing fee to get a copy to play with it. At the same time, I think his implication that this now "breaks" SecureString is a bit alarmist.

Let's face it - all Security is "reversible", if it wasn't, it would be useless. So to imply we can't use SecureString because someone has figured out how to 'piece together' its memory, is overdoing it a little.

SecureString wasn't designed as a "SilverBullet" to secure all data. Like most security "defense in depth designs", it is meant as another 'step' , or 'speed bump' in making it more difficult to break into a system. Like most steps in a defense in depth architectures, each individual step can usually be broken when attacked in isolation (with enough time)

When you think about it, the potential 'hacker' in this scenario would need to have some fairly significant privileges in order to access the memory of the machine, and if that is the case, it's pretty much "game over" anyway.

The same holds true for the ability to "inject" new Principal objects into a thread. A potential hacker would need to have high proves to a machine, and have a fairly intimate knowledge of the application in order to pull this off (something I'll admit could certainly happen in a 'smart client' scenario).

I see this product as a great debugging and testing utility, and yes, another tool in a potential attacker's arsenal for breaking into a system.

Developers should continue to use SecureString, but understand the ways in which it can be "broken", and also the potential dangers when running their processes as Admin on the client. The key to protecting against this type of attack is not to stop using SecureString, but rather to run applications with least privilege, and potentially obfuscate Client code and Principal Names when using SmartClients

Guidance Library filled with security goodness!

2006-10-06T23:50:00Z

The folks over at the Patterns and Practices Team have done it again with the Guidance Library - containing all kinds of best practices, mini "How-Tos" and coding samples for .NET.

What's great about this site is that you can categorize the best practices by topic, including security, and create your own check lists for developers.

This is great - as now, I don't need to go to dozens of web sites to get guidance and best practices on security, I can just go here.

Joy!

Don't be a Security Nazi

2006-10-04T15:34:00Z

I was out at a customer site last week and needed to have access to their internal corporate network to do some work for the week.

Their process for providing access to outside consultants was actualy quite mature - basically, I needed to send an email to an internal address asking permission for access. A series of emails were returned to me, containing user account information along with a very complex 18 character password.

The only problem with this process was that the security policy for my domain wouldn't allow me to change my password to one that was easier to enter! This meant that anytime my machine timed out due to inactivity, I needed to re-enter the 18 character password again! To make things worse, I needed to log onto 3 different machines in the domain to get my workdone - each of which would timeout at regular intervals. So, as a result, there were times during the day that that I needed to re-enter the 18 character complex password 40-50 times in order to get my work done!

I went to the manager who had hired me for the engagement, but he just shook his head and told me that they had been complaining about this policy for months - but their "Security Nazis" wouldn't let outside consultants change their temporary passwords - even through the accounts were only good for 24 hours anyway.

Needless to say, in order to get my work done, I needed to write down my password on a piece of paper and leave it on my desk all day so I could keep re-entering it (I find it hard to memorize H%10v35x!54hb800gb). And naturally, there were times during the week when I went to lunch or the bathroom and accidentally left that piece of paper next to my computer.

So what is the message here? Well, there are two that come to mind:

1. If you set security policy for a company, and you make security difficult for your users - people will not want to work with you. Intead of thinking of the security team as partners, people will think of you as the enemy and avoid you at all costs.

2. If you make security an impediment for people to get their job done, they will (eventually) find a way around your security - creating an even bigger security problem.

This second point should be on a stone tablet somewhere, as I've seen so many instances of it over the years. In my circumstance as a consultant, I wrote down the password on a piece of paper and left it on my desk as I needed to refer to it every 15 minutes. In other instances, I've known of people setting up 'back doors' to "get around" security, or using the good 'ole boy network to get access to resources.

In either case, I'm sure there were some good reasons for setting up the security policy the way they did. Their flaw was in their failure to properly collect and respond to feedback from their users on any suggestions for improvement in policies handed down from above.

So in the end, when setting up security policies for an organization, it is essential to collect feedback from your users, and even modify security policies if necessary, to accomodate the needs of the business. The central security team of any organization needs to be thought of as partners in a business, not the enemy.

Two kinds of people - and the Orcas CTP as a VM!

2006-10-04T15:20:00Z

There is an old saying out there:

There are two kinds of people in the world - those who have lost all of their data, and those who will!

I now count myself in the party of the first part. To make a long story short, I decided to upgrade to Windows Vista CTP a few weeks ago. While Vista was great, there were some compatibility problems with Virtual PC (which I need for my job) so I had to go back to Windows XP SP2. During this process of formatting my drives, somehow, my external drive got whacked!

In the end, I was able to recover most of my files (spent the entire weekend doing so), but I was forced to do a post mortem on why this happened.

Basically, it was because I didn't follow my own procedures on proper backup of my files, but a contributing factor was my desire to try out a new set of technologies - and then re-ghost my machine when I needed to go back and do real, customer work (how many times has this happened to you!)

We'll, I just noticed that the new Visual Studio ORCAS CTP is being released as a VM! This is fantastic news, as it means developers can work on the new technology, without messing with their primary machine configurations - and eventually having to re-ghost their machines when things go wrong.

I hope we start doing this for all of our new CTPs and Beta products. While it does create longer download times (+5 hours on a T1 line), I think it will lead to a greater acceptance from programmers who don't want to install software on their primary machines.

Problems with Vista Security in Europe

2006-09-12T16:42:00Z

I was wondering when this issue was going to come up in the anti-trust discussions. It seems as if the EU commission is raising concerns that the 'bundled' security features of Microsoft Vista might block out competitors in the security space.

To me, (and I'm really trying hard to not be bias here), the decision to add additional security requirements and features to our products is one that is completely driven by our customers, not by some hidden agenda to wipe out a competitor.

Back before the days of the TrustWorthy Computing Initiative at Microsoft, our customers spoke in very clear terms to Mr. Gates that security was of their biggest concerns when using Microsoft products. As a result of this customer feedback, Microsoft has spent the last ~5 years completely re-vamping the way it develops software through structured security engineering and the SDL (Secure Development LifeCycle) procedures.

I don't want to trivialize the concerns of the EU commission or Microsoft's need to comply with their rulings, however; to me, this is clearly a case of Microsoft taking action against a Threat Model which showed a vulnerability that required a certain set of mitigations.

Credit Card Companies form security council

2006-09-08T17:26:00Z

It seems that the evolving PCI (Payment Card International) standard is getting more support with all of the major credit card companies agreeing to get together to form the new Security Standards Council.

While the PCI is fairly high level right now, it is requirement 6, calling for secure applications which catches my eye. I'm going to keep my eye on this group and see what lifecycle recommendations they make to development groups.

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

Does AOL have a Secure Development LifeCycle in place?

2006-08-22T16:54:00Z

Yet another set of headlines this week about data being leaked accidentally from internal employees. This time, the news is from AOL, where information was posted on-line about user searches. According to AOL

“This incident took place because some employees did not exercise good judgment or review their proposal with our privacy team,” Jonathan F. Miller, the chief executive, wrote in an e-mail message to employees released yesterday afternoon. “We are taking appropriate action with the employees who were responsible.”

The way I see it, one of two things probably happenned here:

1. A set of policies and procedures was defined by the company that called for some kind of SDL (Secure Development Lifecycle) and Threat Modeling process be in place for all development efforts. The project management team and engineers did not inforce these policies or they were ignored. As a result, when this mistake was made, the people who ignored the policy were fired. To show that executives are ultimately accountable for this kind of problem, the CTO was also 'asked to leave' the company.

2. There is no SDL or Threat Modelling process in place at AOL. Security is approached in an Ad Hoc or unstructured way by the different development teams. When the engineers released the application and data to production, they did their best to think about security, but just didn't think about this particular threat scenario. When the problem occurred, management decided that 'heads would roll' to show how serious they were, and started firing people. When called on the carpet to explain, the CTO didn't really know what happened (she had only been in the role for a year) and she was basically fired.

I would bet it was something like the second scenario. Sure, people need to be held accountable in the case of gross negligence or apathy to procedures - everyone wants that. But is that REALLY what happened here? Did the AOL "employees responsible" really ignore procedures, or is the real culprit, their management process around security, to blame?

If that is the case, then firing employees and management is not the answer. Instead, their executives should be asking "what policies and procedures should be in place to prevent this kind of thing happenning". In other words, they should fire their existing process, not the employees who just didn't think of this particualr threat scenario (I wouldn't have!)

Sure, AOL may technically have a "privacy team" in their organization, but did the project managers and engineers know who they were? Did the development lifecycle have a "security push" defined in the project timeframe which called for a meeting with the privacy team? Was a Threat Model even created for this initiative?

The is a classic example of why a structured approach to security, through something like the SDL Methodologies, should be incorporated into the development process.If an AOL SDL called for a mandatory "security review" by the privacy team, this problem may have never occurred.

We can only hope the project managers around the world are updating all of those GANT charts out there - to include elements of the SDL in their process - otherwise - we might be seeing alot more of this.

New Threat Modeling Tool and 'hip' video released

2006-03-10T18:09:00Z

So everyone is talking about the new .NET 2.0 based threat modeling (Beta) that has just been released. From my initial fly-by, it looks like a very different approach than the older tool which relied on software developers to learn and master the concepts of STRIDE and DREAD in the analysis.

I go around all the time talking to ISVs about writing secure code, and when I show them the older tool and process, they generally roll their eyes at me like I'm living on another planet. They all subscribe to the concepts of 'Threat Modeling", but the idea of spending hours, weeks, or even months setting up the model and all of its attributes came across like some kind of punishment. Everyone seemed to know it just wasn't going to happen.

The new tools seems to drastically simpliyfy the process, eliminates the STRIDE and DREAD categorizations, and creates tools to automatically generate threat trees based upon basic business descriptions of roles and processes. It also seems to allow for the creation of models from pre-defined starter templates, which many shops have asked for.

The tools looks great, and I plan on pushing it to my ISVs right away.

There is also an associated marketing video which has recently been released, which sells the idea that the tool can be used by people who know little or nothing about security - to help secure a system.

I've always disliked this type of marketng, which in my opinion does more harm than good. It sets the expectatoin, that somehow, you can use this magical tool to 'secure' your system.

Back in the 90's, as an industry, we tried selling the idea of 'RAD' (Rapid Application Development), in which programmers didn't need to understand the underlying architecture to 'glue' together their software. While the idea of reusable components is great, many project managers got the wrong idea about this which eventually led to DECADES of crappy, buggy software that didn't scale well and was a nightmare to maintain. We all know that there are just no shortcuts to quality software - all programmers need to understand that underlying technology stacks and design patterns to write quality software..

So why are we now trying to sell the same idea for security, that developers don't have to understand basic security mechanics and architecture, and can just use this magic 'RAD' tool to secure a system! That's analagous to telling civil engineers that they can use a RAD software tool to design bridges, but they don't need to bother with the fundamentals of physics and load analysis!

In my mind, this is why so much bad software has been created over the last 30 years - because management are sold on the idea that there are shortcuts in software engineering, that programmers can simply cut and paste components together, and use magical tools like this to do the real work for them.

So I see a great tool here that I'm going to start selling to my customers. But please, spare us the markenting videos with fancy graphics and drum-beats in the background. We had enough of them in the 90's. Send developers to the Patterns and Practices software engineering site instead.

Changing the default membership and role provider in Visual Studio 2005

2006-02-17T17:12:00Z

When you initially install VS2005 and start to use the default membership and role providers for security, you usually use the default SQL provider for SQLExpress on your local box.

But what if I want to later change from SQL Express, and instead use a full blown version of SQL2005 , or some other data store from my role and membership data?

You would think that you could go into the new ASP.NET configuration tool, and change it there - but you can't.

After quite a bit of time, I found that you need to manually change the definition in web.config for your LocalSQLServer:

<connectionStrings>

<remove name "LocalSqlServer"/>

<add name "LocalSqlServer" connectionString="Data Source=SERVERNAME; Initial Catalog=aspnetdb;Integrated Security=True" providerName="System.Data.SqlClient"/>

</ConnectionStrings>

This will point to the new aspnetdb database that you created on SQLServer, with schemas created through the aspnet_regsql utility.

Naturally, this new schema will be empty, and you will need to script over the data from your old provider database to the new one manually

AJAX poses security, performance risks

2006-02-17T16:54:00Z

With the increasing popularity of Ajax/Atlas as the new 'holy grail' of development, it easy to predict the number of security problems in all of that javascript and xml flying all over the place.

The folks over at the secure development mailing list have some references to an e-week article on some of the potential security risks with AJAX, and also have a nice paper on some of the things to watch out for as an ajax developer.

"AJAX dramatically increases the amount of XML network traffic being transmitted, exposing applications to Web services vulnerabilities; AJAX extends Web services from business-to-business to business-to-consumer and transforms a user's Web browser into a Web services portal, thus exposing it to potentially corrupted data that can cause the browser to crash or perform poorly; malformed messages can disrupt server performance due to excessive parsing and exception handling; and XML messages can consume more than double the bandwidth of traditional binary data formats, leading to systemwide performance degradation"

Thanks to Rob Hurlbut for putting this up in his blog.