ACE Team - Security, Performance & Privacy

Simple Rules To Stop Bad Guys

Hi, RockyH here,

I was browsing for IT security news from the hotel this evening and came across this gem:

That’s it. Of course there is no information about who to email, and why should their be. If they can’t figure out how to tell the difference between malicious traffic and real traffic other than by blocking entire IP ranges, there is little chance they could filter out spam should their email address be harvested off their web page.

After saying that I checked again the following night and they had amended their little blocked access page:

Besides, at best this is a triviality. It’s security theatre. When you set your machine to use a proxy through work or something like TOR you can get right past this kind of thing.

Almost every modern firewall product can do packet inspection to look for genuine malicious attack patterns.  In the modern Internet there is no need to do blind IP Range blocking. This was never a good idea in the first place, after all what you have really done is create a Denial Of Service (DOS) attack on yourself. Good thinking.

That reminds me of a guy who told me about the protection he built into his web site to prevent SQL injection. He said, “What I do is look for SQL injection attacks like OR 1=1 and if I find one, I kill the web application with an exception.” Right, so now all I have to do to take down your site is send you an ‘OR 1=1’ in the search page and Blamo, your site goes offline. Good thinking.

Ok everyone, pay attention! The best way to handle these kinds of things is a very simple tactic called Input Validation. Say it with me now, Input Validation!

All your commercial firewalls can do stateful packet inspection and drop suspect packets. Things like Threat Management Gateway (TMG) can even inspect traffic at the logical level and filter out known bad attack strings such as those used to exploit known vulnerabilities. Now I don’t recommend this kind of black-list inspection as your only means of defence, but it’s good to put a rule in place to plug the whole while the developers work on the patch.

With over 90% of the actual attacks happening at the application layer, this is where you should concentrate your defensive measures. It all starts with the software. If you have in-house developed applications, you can no longer afford to rely on goofy blacklisting mentioned above.

Here are a few simple rules for application development that will stop a vast majority of the attacks out there.

Rule #1: Implement a Secure Development Lifecycle in your organisation.

This includes the following activities:

• Train your developers, and testers in secure development and secure testing respectively
• Establish a team of security experts to be the ‘go to’ group when people want advice on security
• Implement Threat Modelling in your development process. If you do nothing else, do this!
• Implement Automatic and Manual Code Reviews for your in-house written applications
• Ensure you have ‘Right to Inspect’ clauses in your contracts with vendors and third parties that are producing software for you
• Have your testers include basic security testing in their standard testing practices
• Do deployment reviews and hardening exercises for your systems
• Have an emergency response process in place and keep it updated

If you want some good information on doing this, email me and check out this link:
http://www.microsoft.com/sdl

Rule #2: Implement a centralised input validation system (CIVS) in your organisation.

These CIVS systems are designed to perform common input validation on commonly accepted input values. Let’s face it, as much as we’d all like to believe that we are the only ones doing things like, registering users, or recording data from visitors it’s actually all the same thing.

When you receive data it will very likely be an integer, decimal, phone number, date, URI, email address, post code, or string. The values and formats of the first 7 of those are very predictable. The string’s are a bit harder to deal with but they can all be validated against known good values. Always remember to check for the three F’s; Form, Fit and Function.

• Form: Is the data the right type of data that you expect? If you are expecting a quantity, is the data an integer? Always cast data to a strong type as soon as possible to help determine this.
• Fit: Is the data the right length/size? Will the data fit in the buffer you allocated (including any trailing nulls if applicable). If you are expecting and Int32, or a Short, make sure you didn’t get an Int64 value. Did you get a positive integer for a quantity rather than a negative integer?
• Function: Can the data you received be used for the purpose it was intended? If you receive a date, is the date value in the right range? If you received an integer to be used as an index, is it in the right range? If you received an int as a value for an Enum, does it match a legitimate Enum value?

In a vast majority of the cases, string data being sent to an application will be 0-9, a-z, A-Z. In some cases such as names or currencies you may want to allow –, $, % and ‘. You will almost never need , <> {} or [] unless you have a special use case such as http://www.regexlib.com in which case see Rule #3.

You want to build this as a centralised library so that all of the applications in your organisation can use it. This means if you have to fix your phone number validator, everyone gets the fix. By the same token, you have to inspect and scrutinise the crap out of these CIVS to ensure that they are not prone to errors and vulnerabilities because everyone will be relying on it. But, applying heavy scrutiny to a centralised library is far better than having to apply that same scrutiny to every single input value of every single application.  You can be fairly confident that as long as they are using the CIVS, that they are doing the right thing.

Fortunately implementing a CIVS is easy if you start with the Enterprise Library Validation Application Block which is a free download from Microsoft that you can use in all of your applications.

Rule #3: Implement input/output encoding for all externally supplied values.

Due to the prevalence of cross site scripting vulnerabilities, you need to encode any values that came from an outside source that you may display back to the browser. (even embedded browsers in thick client applications). The encoding essentially takes potentially dangerous characters like < or > and converts them into their HTML, HTTP, or URL equivalents.

For example, if you were to HTTP encode <script>alert(‘XSS Bug’)</script> it would look like: &lt;script&gt;alert('XSS Bug')&lt;/script&gt;  A lot of this functionality is build into the .NET system. For example, the code to do the above looks like:

Server.HtmlEncode("<script>alert('XSS Bug')</script>");

However it is important to know that the Server.HTMLEncode only encodes about 4 of the nasty characters you might encounter. It’s better to use a more ‘industrial strength’ library like the Anti Cross Site Scripting library. Another free download from Microsoft. This library does a lot more encoding and will do HTTP and URI encoding based on a whitelist. The above encoding would look like this in AntiXSS

using Microsoft.Security.Application;
AntiXss.HtmlEncode("<script>alert('XSS Bug')</script>");

You can also run a neat test system that a friend of mine developed to test your application for XSS vulnerabilities in its outputs. It is aptly named XSS Attack Tool.

Rule #4: Abandon Dynamic SQL

There is no reason you should be using dynamic SQL in your applications anymore. If your database does not support parameterised stored procedures in one form or another, get a new database.

Dynamic SQL is when developers try to build a SQL query in code then submit it to the DB to be executed as a string rather than calling a stored procedures and feeding it the values. It usually looks something like this:

(for you VB fans)

dim sql
sql = "Select ArticleTitle, ArticleBody FROM Articles WHERE ArticleID = "
sql = sql & request.querystring("ArticleID")
set results = objConn.execute(sql)

In fact, this article from 2001 is chock full of what NOT to do. Including dynamic SQL in a stored procedure.

Here is an example of a stored procedure that is vulnerable to SQL Injection:

Create Procedure GenericTableSelect @TableName VarChar(100)
AS
Declare @SQL VarChar(1000)
SELECT @SQL = 'SELECT * FROM '
SELECT @SQL = @SQL + @TableName
Exec ( @SQL) GO

See this article for a look at using Parameterized Stored Procedures.

Rule #5: Properly architect your applications for scalability and failover

Applications can be brought down by a simple crash. Or a not so simple one. Architecting your applications so that they can scale easily, vertically or horizontally, and so that they are fault tolerant will give you a lot of breathing room.

Keep in mind that fault tolerant is not just a way to say that they restart when they crash. It means that you have a proper exception handling hierarchy built into the application.  It also means that the application needs to be able to handle situations that result in server failover. This is usually where session management comes in.

The best fault tolerant session management solution is to store session state in SQL Server.  This also helps avoid the server affinity issues some applications have.

You will also want a good load balancer up front. This will help distribute load evenly so that you won’t run into the failover scenario often hopefully.

And by all means do NOT do what they did on the site in the beginning of this article. Set up your routers and switches to properly shunt bad traffic or DOS traffic. Then let your applications handle the input filtering.

Rule #6: Always check the configuration of your production servers

Configuration mistakes are all too popular. When you consider that proper server hardening and standard out of the box deployments are probably a good secure default, there are a lot of people out there changing stuff that shouldn’t be. You may have remembered when Bing went down for about 45 minutes. That was due to configuration issues.

To help address this, we have released the Web Application Configuration Auditor (WACA). This is a free download that you can use on your servers to see if they are configured according to best practice. You can download it at this link. [edited to fix link]

You should establish a standard SOE for your web servers that is hardened and properly configured. Any variations to that SOE should be scrutinised and go through a very thorough change control process. Test them first before turning them loose on the production environment…please.

So with all that being said, you will be well on your way to stopping the majority of attacks you are likely to encounter on your web applications. Most of the attacks that occur are SQL Injection, XSS, and improper configuration issues. The above rules will knock out most of them. In fact, Input Validation is your best friend. Regardless of inspecting firewalls and things, the applications is the only link in the chain that can make an intelligent and informed decision on if the incoming data is actually legit or not. So put your effort where it will do you the most good.

InfoSec A&P Suite: How to Install & Configure

Hi everyone, Diane here.  Recently the Information Security Tools (IST) Team released the Assessment & Protection (A&P) Suite. If you missed the overview on the A&P suite, check out the Information Security blog.  The Web Protection Library v1.0 (WPL) Security Runtime Engine (SRE) has been significantly updated.  Anil Revuru (RV) from the IST team discusses these updates in his recent blog and also provides a walkthrough on how to configure WPL SRE.  The WPL (formerly Anti-XSS Library) has also been expanded and includes new mitigation for attacks such as SQL injection, cross-site request forgery (CSRF), setting enforcement like SSL & HTTP_ONLY cookies and more.  RV discusses these attacks in more detail in his recent video “Using the Web Protection Library (WPL) - CTP Version.” 

In addition, for the assessment tools of the A&P suite which includes the Code Analysis Tool for .NET (CAT.NET) and Web Application Configuration Analyzer (WACA), RV talks about how to install and configure  CAT.NET v2.0 in his blog “How to Run CAT.NET 2.0 CTP”.  To configure the WACA tool RV provides guidance how to setup this tool in his video “Using Web Application Configuration Analyzer (WACA) - CTP Version”.

The CTP (Community Technology Preview) is available in Microsoft Connect – Information Security Tools.  Read CTP announcement and follow the Information Security Tools team blog.

-Diane Talvo
Security Awareness Program Manager
Microsoft Information Security

Introducing the InfoSec Assessment & Protection Suite

The Information Security Tools (IST) team has released the InfoSec Assessment & Protection (A&P) Suite.  It’s a suite made up of protection and assessment tools which include:

• Web Protection Library (WPL) - an umbrella for several libraries and runtime modules including the Microsoft Anti-Cross Site Scripting Library v3.1 (Anti-XSS V3.1) and SRE, packaged together with Anti-XSS when downloaded. Helps prevent XSS and SQL injection attacks, but instead of having to make changes to the code (which is manual and costly), a user makes changes to the application configuration and not the code (white list/black list). Watch the podcast, “Enhanced Web Protection Library,” as Anil Revuru (RV) from the IST teams shares the details of the new expansion of this library.
• Code Analysis Tool for .NET (CAT.NET) - a managed code security source code scanning tool that has been totally rewritten.
• Web Application Configuration Analyzer (WACA) designed to scan your development environment against best practices for .NET security configuration, IIS settings, SQL Server Security best practices and some Windows permission settings.

Read more about the the A&P suite here and watch the podcast, “Assessment and Protection Suite,” as Anil Revuru (RV) and Mark Curphey from Microsoft IST team discuss the future of this suite of tools.

To download these tools for free, you will need to register on the Connect site. Once you’ve registered, you can download the tools below directly. Get the latest on the A&P Suite on the IST Blog.

Download, A&P Suite will include:

• CAT.NET 2.0 CTP
• WPL 1.0 CTP
• WACA 1.0 CTP

-Diane Talvo
Microsoft Information Security

Dogfooding: How Microsoft IT Information Security Dogfoods: Product Influence

Hi Steven Michalove here, I’m a principal program manager on Microsoft IT’s Information Security (InfoSec) group. For the last of couple weeks, we’ve been talking about Microsoft IT’s (MSIT) dogfooding process, known as the First & Best program. Concluding this dogfooding blog series, I would like to share with you how we help influence the development of products from an information security risk perspective. If you missed the prior blogs, read Mark Smith’s blog for an overview of the process, Don Nguyen’s blog for Phase 1 and Price Oden’s recent blog for Phase 2.

A little background on me, I am a subject matter expert that works with security features in the Windows OS. Our team mission is to deploy controls that mitigate security risks for Microsoft. In the last few years I have been working in the area of Desktop Encryption and the deployment of BitLocker^TM internally within Microsoft. As part of the First & Best program, we act as early adopters and influencers of specific features like BitLocker^TM. Our role stretches throughout the entire lifecycle of a product release to test, pilot, and improvements to a product while at the same time making a measureable impact on reducing risk.

Additionally, I am a deployer of new security technologies where I get an early look at Microsoft technologies. Basically we get the bits earlier than our customer and we can log bugs and feature requests directly with our internal product developers. Since we deploy and also evaluate the deployment early, we get a look at the features while there’s still an opportunity to both test the technology and provide input into the features themselves. We generally give three kinds of feedback and the focus may change depending on where in the development lifecycle the product or feature may be. Those three kinds of feedback usually are 1) Technical errors that often indicate some kind of bug or programming error, 2) Manageability issues and documentation that influence enterprise scale deployments and 3) Feature feedback and requests. Along with providing feedback to the product teams, we’ll often brainstorm and discuss options with the developers. Our feedback really depends upon the product lifecycle, specifically how early in the process we are involved. Additionally, often times we will also develop shared goals and pilot programs (both mandatory and optional) with target numbers. For example, we may say we want to install 1000 systems with a pre-Beta build and turn on a specific feature. We’ll then build the measurement instrumentation to support the shared goals and recruit users to help.

An example of MSIT’s involvement with influencing a product is the move from Vista to Windows 7 specifically around enterprise manageability and deployment ease of BitLocker^TM. The Vista splitloader that’s needed for BitLocker^TM is 1.5G. However, it can be hard to retrofit onto a system with existing drives. In Windows 7 not only did we shrink that to 100Mb (depending on certain options) but also, with MSIT’s input, improved the shrink API code base to help make the shrink operation itself more reliable. So while these improvements did not influence the BitLocker™ feature itself, it improved the deployment footprint of the feature.

The dogfooding process is an iterative approach. We’ve been early adopters of our own technology for quite some time. Some questions we ask ourselves are, “what will our universe will look like in three to five years; will we see new technologies and threats; if we could achieve a dream state, what would that be?” If you’re thinking about implementing a dogfooding program in your own company, here are a few things to consider. Primary on the list is management support. The total cost of ownership is much higher as you test technologies in the production environment. For example, we have more versions of operating systems deployed than most companies, even more than our TAP customers, since we get software very early in the pre-release cycle. Most companies would not consider these early versions production ready for at scale deployments. We do it differently and deploy these early versions into our production environments at scale to aid in the product development lifecycle – we take the first and best objective into our operation and make it part of our overall footprint. That is how Microsoft does IT.

Making the decision to use the production IT environment as an incubator for new technologies is a business decision. We have to both support and upgrade, as well as migrate and deploy, constantly. This can be expensive and that’s where having a strong business sponsorship is necessary. Seek specific measurable outcomes and boundaries. Agreeing on quantitative shared goals and resourcing them is a constant challenge but it needs to be a continuous process. Next, setup a mechanism to recycle the knowledge you gain. If early deployments teach you something, make sure you have the knowledge management in place to leverage this through to the production (finished, released product) systems deployments.

Eventually a “dogfood” cycle ends and things move to a full production environment. You can gain a lot of speed with your early learnings. Set yourself up for that. Lastly, be prepared to deal with outages and bugs in early versions; software is unpredictable at scale so you need to have a plan “B” prepared so you can back out or limit unintended consequences. You can almost always be sure the thing you least expect will be discovered in pre-release versions, plan ahead and be prepared for the unexpected. The upside is because Microsoft IT uses early versions the released versions are stable and predictable.

Hope you have enjoyed our dogfooding blog series. Watch my recent video, "Dogfooding: Deplyoment & Product Influence," as I discuss in more detail on our dogfooding process.

- Steven Michalove
Principal Program Manager 
Microsoft Information Security

Dogfooding: How Microsoft IT Information Security Dogfoods, Phase 2: Perform an Assessment of the Features Only

Hi Price Oden here, I’m a principal senior security architect on the Microsoft IT Information Security (InfoSec) group. Dogfooding is part of Microsoft IT’s culture.  It’s where Microsoft IT (MSIT) plays an important role and service for Microsoft’s enterprise customers.  Despite the challenges of mixing testing and production on the same network and environment, MSIT trials new products at large scale in a production environment to identify and address deployment, operational and functional issues before those products reach Microsoft’s enterprise customers.  In this blog, I’ll talk about the next phase of our dogfooding process, Phase 2: Perform an Assessment of the Features Only. To get an overview of the dogfooding process, read Mark Smith’s blog and also read about Phase 1 in Don Nguyen’s blog.

In phase 2, after the ACE Team performs a security design review, the Security Operations Planning and Strategy Team which I’m a part of, we conduct an assessment of the features only.  For this assessment, we assess security-related features and technologies in upcoming Microsoft software products to determine how they help us in MSIT’s efforts to reduce risks in the enterprise.  Our team works with the product groups to obtain the design and functional specs and early beta builds.  If the product or feature is a good candidate, we’ll dive into technical details with the product group.  In addition, if necessary we’ll install and configure the product and tests use cases.  One example that our team was involved with was the Windows 7 BitLocker to Go^TM feature.  An industry trend is the explosion of removable media used in the enterprise. We prescribed Windows 7 BitLocker to Go^TM as an excellent risk mitigator to protect removable media. 

Many enterprises are early adopters so if you’re thinking about starting a dogfooding process in your own organization, here’s a couple of things to consider.  Rollouts to test drive new technologies can carry much of the same resource expenditure that deploying any product would have.  Therefore it may be prudent to go into all deployments with a commitment to eventual production use; you can focus on a measured rollout that occurs at a non-disruptive pace.   Additionally, having a vision in place is extremely valuable to guide the decision process of which technologies to deploy.  Against the backdrop of a vision, each technology can be assessed to determine if it moves the organization closer to reaching its vision and if the candidate technology strategic or not.  With that assessment, the organization may decide to be conservative with regards to how much financial commitment it makes in non-strategic technologies so that it doesn’t become entrenched and prohibit replacement when a strategic technology becomes available.  Regardless, once a decision is made to deploy, the deployment itself needs to be well planned.

To hear more details about this phase of our dogfooding process, watch our recent video, “Dogfooding Security-Related Features” where Yale Li, senior security architect, and I share some of our experiences.  Next time Steven Michalove will discuss how we influence products in the next phase of the dogfooding process...stay tuned.

Dogfooding: How Microsoft IT Information Security Dogfoods, Phase 1: Conduct a Security Design Review

Hi Don Nguyen here, I’m a senior security engineer with the Microsoft Information Security's (InfoSec), ACE Team.

Continuing with our blog series on dogfooding, today I will be talking about phase 1: conduct a security design review, of our formal dogfooding process called, the First & Best program. In case you missed it, read Mark Smith’s recent blog here where he provides an overview of our dogfooding process.

In phase 1 of our dogfooding process, a security design review is conducted and it’s performed by our own assessment team, the ACE team. In a security design review we’re looking at additional features that might affect our policies. So basically a new feature can change our policy and if needed, we may need to modify the policy. From our review, any finding that may affect policy is communicated to our policy group. This helps ensure our internal policies are evolving along with our new technologies. For example, SQL 2005 provided a transparent data encryption to meet our internal security standard for sensitive data encryption. We assessed the encryption method and updated our policies to accept this method. The same can also be true the other way around, where we have a security policy and the product/feature may be suited at a consumer-level, but can’t be deployed in our enterprise environment per our security policies.

Also in this phase a risk assessment is performed. Anytime you add or change feature sets, the relative risk associated with the change needs to be reviewed and also existing risks will need to be assessed. Additionally with new products, new network risks can be introduced and we want to ensure these risks are identified and addressed. When we perform a risk assessment which enables the new features, this can increase risks to the network, however, this helps us determine security controls needed to mitigate a risk. Mitigation is provided to the product teams. After the assessment is completed, we provide feedback to the product teams from the context of an enterprise environment and how Microsoft IT will deploy a product, usually the enterprise features specifically.

In the end, success in the dogfooding program is really, seeing the overall successes over time, seeing products evolve and become more secure. Getting the opportunity to make a product more secure, working with the product teams and making a product more “enterprise-ready” is really key. If you’re interested in starting a dogfooding program in your own organization, here are some things you can consider:

• Determine if your organization wants to run beta software in a production environment. Make sure the beta software has feature/updates that your organization can utilize. Don’t try to beta test everything, only things that you actually expect to use as an enterprise. We test everything, but that’s our core business.
• Identify what you want to dogfood and create a dogfood plan with a start and end date per beta product/project.
• Establish a deliverable, basically a migration roadmap from when a product is beta to RTM (release to market).

Check out my recent video where I talk more about this phase. Next time we will discuss the next phase of our dogfooding process, stay tuned…

-Don Nguyen
Senior Security Engineer
Microsoft Information Security, ACE Team

Risk Management in Risk Tracker

Hey there, my name is Sarah Pickard and I am a Senior Program Manager on the Microsoft Information Security Risk Management team.  You have seen some blogs by Vineet Batta on the external release of Risk Tracker which is an application Information Security uses to - - well, track risk.   To find out more information about Risk Tracker and how my teams uses it, please see the posted videos.

In upcoming blogs I will give more information about how we have entered and structured risk data in Risk Tracker, how we have started tracking risk mitigating projects in Risk Tracker, and how ultimately we expect that Risk Tracker will help Information Security address the most risk with the least amount of resources.  As we all know, more with less is the name of the game. Feel free to contact me (spickard@microsoft.com) with questions.  I look forward to chatting with you all.  Sarah

Dogfooding: How Microsoft IT's Information Security Dogfoods

Hello Diane here.  Do you ever wonder how Microsoft’s IT Information Security (InfoSec) is involved in the dogfooding process?  This week we’re kicking off our blog series on dogfooding.  It's a formal program in Microsoft IT known as the First & Best prgram.  Recently Mark Smith, senior program manager on Microsoft’s InfoSec group, in his blog provides an overview of the First & Best program, along with his video.  In the next coming weeks, you’ll get a glimpse into our process  as we walk through the phases.   Stay tuned.

-Diane Talvo
Security Awareness Program Manager
Microsoft Information Security

How to Integrate Risk Tracker with Internal HR Feeds

Organizations who would like to deploy the Risk Tracker v1.0 application in their own environment, Vineet Batta, senior software developer on Microsoft’s IST team, shares how in his blog, “How to Integrate Risk Tracker with Internal HR Feeds.”  Additionally, to get an an overview of this application and it’s key features, also read Vineet’s blog, “Risk Tracker v1.0 Release.”  Visit the Information Security Tools Blog for more information on security tools.

-Diane Talvo
Security Awareness Program Manager
Microsoft Information Security

Risk Tracker v1.0 Release

The Microsoft Information Security Tools (IST) team releases Risk Tracker version 1.0 application.  Risk Tracker built on CISF (Connected Information Security Framework) framework will help organizations manage, track and report on risks.  Vineet Batta, Senior Software Developer from Microsoft’s IST team, in his recent blog, “Risk Tracker v1.0 Release” provides an overview of the features supported by this release (CTP).  If you haven’t seen it, watch the video “Risk Tracker: Reducing Risks at Microsoft,” as Sarah Pickard, Senior Security Program Manager from Microsoft Information Security team and Mark Curphey, Product Unit Manager from Microsoft Information Security Tools (IST) team discuss how the business will use Risk Tracker and how it will help manage risk.

Read more about this application and other security tools on the Information Security Tools Blog.

-Diane Talvo
Security Awareness Program Manager
Microsoft Information Security

Create a Response Time Graph

Spending my last 4 years helping Microsoft’s enterprise customers improve their line of business application performance, I have interacted with many project managers, business analysts as well as executive officers.  Given the non-technical nature of their roles, the first thing that comes into their mind on the subject of application performance is, “How does my application perform under a certain workload?”

The old saying “A Picture Is Worth A Thousand Words” can certainly be seen on a Response Time Graph. Below you will find a real-world sample I recently put together for a customer while working on their company portal.  There are 2 things that are worthwhile to highlight here:

• Somewhere between 420 to 450 concurrent users, the average homepage response time exceeded 3 seconds which is the company’s defined performance SLA upper limit.
• Using data available from the graph, the homepage response times between 50 to 500 concurrent users are predictable.  This answered the project manager’s inquiry on “how does my application perform under X users”.        

To create a meaningful Response Time Graph, it does not require the purchase of expensive tools or running a dozen application load tests.  At a minimum you will need:

• Visual Studio 2008 Team Test Edition or Team Suite (90-day trial available for download here)
• Log Parser 2.2 (free download available here)
• IIS (Internet Information Services) Log
• Office Excel

The step-by-step instructions provided below do not cover the basics of using Visual Studio testing features such as creating a web test.  For more information, please look at a list of comprehensive resources on the web available off Ed Glas's blog.  Also consider this 7-minute web test step-by-step primer by A.C.E. Performance Engineer Chris Lundquist.

1)      Enable the time-taken field in your target application’s Internet Information Services (IIS) log under IIS Manager.  Leave the default log format of W3C.

2)      Create a new folder under the IIS Log directory (e.g., Test01) and assign it to store the log files.

3)      Execute your load test with the Step Load Pattern.  As illustrated in the table below, the test begins with 10 users, incrementing by 10 users every 20 seconds until 500 concurrent users are loaded.

4)      Execute the test and record the start and end time (also available in the Load Test Summary report).

5)      Copy the IIS logs to a client workstation with LogParser and Excel installed.

6)      Open Excel and create a new spreadsheet with 3 columns: timestamp (A), # of concurrent users (B) and response time (C).

7)      Populate column A and B with information you already know either manually or using an Excel formula.  For example based on the load pattern defined above I know ~100 users were simulated on the system after approximately 3 minutes into the test.  Alternatively, extract data directly from the graphs (User Load) in Visual Studio.

8)      Calculate the average response time of your test scenario (e.g. an ASPX page or a web service call) using LogParser:

logparser "SELECT TO_LOCALTIME(QUANTIZE(TO_TIMESTAMP(date, time),60)), Avg(time-taken) AS AvgTime INTO C:\MyTemp\Homepage.csv from C:\Users\eddiel\Desktop\LogIn\ex*.log where (To_Lowercase(cs-uri-stem) like '%/s/app/default.aspx%') and sc-status = 200 and cs-method like 'GET' GROUP BY TO_LOCALTIME(QUANTIZE(TO_TIMESTAMP(date, time),60))" -i:IISW3C -o:CSV

The sample query above is used to calculate the average response time on GET requests to “/s/app/default.aspx” resulted in HTTP status 200, based on 60 seconds increment (quantize function).  In other words, I know precisely the average execution time of the portal’s homepage by the minute as user load increases.

9)      Populate column C (response time) in the spreadsheet created earlier by matching the timestamp.  It is fine when there are more LogParser output rows than what you have defined for column A.

10)   Create your Response Time Graph (Scatter with Smooth Line type) in Excel.  Add X and Y axis labels accordingly.

Completing step 1 to step 10 should take less than 30 minutes.  The result is a meaningful Response Time Graph that is illustrating your application performance—a picture that’s worth a thousand words!  I invite your questions and comments.  By Eddie Lau.

Anti-XSS Library v3.1 Released!

The Microsoft Information Security Tools (IST) team has released the latest Microsoft Anti-Cross Site Scripting (Anti-XSS) Library version 3.1.  Read more about Anti-XSS v3.1 on the Information Security blog and watch the video, “Anti-XSS 3.0 Released,” as Vineet Batta and Anil Revuru (RV), Senior Software Developers from the Microsoft Information Security Tools (IST), provide an overview of the Anti-XSS Library and how it can prevent XSS attacks in your application.

-Diane Talvo
Security Awareness Program Manager
Microsoft Information Security

Introducing the Connected Information Security Framework (CISF) and Risk Tracker Version 1.0

The Microsoft Information Security Tools (IST) team has released the Connected Information Security Framework (CISF), a software development framework comprises of API’s and reusable components that is designed to ‘create bespoke or custom information security and risk management solutions.’ Additionally along with this release of CISF, the IST team is also releasing the first custom application using CISF called Risk Tracker version 1.0 that manages and tracks information security risk. Read more about CISF and the Risk Tracker application as Todd Kutzke, Senior Director from Microsoft Information Security, provides an overview in his recent blog, “Announcing the Connected Information Security Framework (CISF) and Risk Tracker.”

-Diane Talvo
Security Awareness Program Manager
Microsoft Information Security

Blog Series: Get Familiar with the SDL-LOB Process. Introduction to Phase Five: Release for LOB

Hello, Anmol here.  As you’ve been following along with me in my blog series on Security Development Lifecycle for Line-of-Business applications (SDL-LOB) , I’ve talked about Phase One, Two, Three and Four.  Today, I’ll discuss the last phase - Phase Five: Release for LOB.  SDL-LOB defines standards and best practices for providing security and privacy for line-of-business (LOB) applications either in development or being planned for development. 

In the Release phase, now that the application is live in production, a post-production assessment takes place. It is important to note that this is a continuous process and all applications/hosts/network devices are in scope. This type of assessment performed by an operations team and involves verification of patch management, compliance, network and host scanning as well as responding to incremental releases for hotfixes and service packs. Typically the assessment occurs on a continuous regular cycle and integrates with an existing management process already in place established by the compliance group. 

Highlight for this phase include:

• Host-level security
  
  • Patch Management
    
  • Appropriate configuration
    
  • Antivirus
    
  • Compliance
    
• Review access control/permissions
  
• Server auditing and logging
  
• Network level security
  
• Application retirement

Under every task given above, there are several security requirements that the application team follows. Here’s the complete list of security requirements here.  Concluding my blog series I’ve talked about all 5 phases of SDL-LOB, providing you a brief highlight of each of the phases.  Take some time and review all phases of the SDL-LOB in detail.  To wrap up, here’s the phases again:

• Phase One: Requirements for LOB

• Phase Two: Design for LOB

• Phase Three: Implementation for LOB

• Phase Four: Verification for LOB

• Phase Five:  Release for LOB

-Anmol Malhotra
Senior Security Engineer
ACE Team

Video Series: ACE Security Consultants from the Field

Kicking off our video series, ‘ACE Security Consultants from the Field,’ Talhah Mir from Microsoft Information Security, talks to two passionate individuals about security.

Watch the podcast, “ACE from the Field: Carric 'DEFCON Goon' Dooley,” as Carric Dooley, Senior Security Consultant from Microsoft ACE Team, talks about his broad security experience including pen testing (on non-Microsoft platforms), the completeness of security and more.

Roger Grimes, Security Architect from Microsoft ACE Team in this video, “ACE from the Field: Roger Grimes & Securing the Internet,” discusses his lifelong passion for making the internet more secure.  He shares his thoughts on how security has evolved, where it stands, how it can be fixed including how most hacks can actually be avoided by the user.

 -Diane Talvo
Security Awareness Program Manager
Microsoft Information Security