ACE Team - Security, Performance & Privacy

Infrastructure Security expert? Microsoft's ACE Team is hiring!

Ahmad - ACE Team — Thu, 21 Oct 2010 20:23:08 GMT

Do you have a passion for security and excited about impacting some of the largest and most complex infrastructure security challenges Microsoft is involved with today? If the answer is yes, you may be a candidate to join the ACE Team.

The ACE (Assessment, Consulting & Engineering) team is the assessment arm of Microsoft’s Information Security & Risk Mgmt. (IS&RM) organization. Our team is a dynamic organization chartered with providing security assessment services to both Microsoft and to Microsoft’s enterprise and public sector customers to help effectively manage security risks. As a part of our charter, we are tasked with sharing and showcasing with external customers how Microsoft manages risks as well as to learn and bring back best practices from Microsoft’s customers to benefit Microsoft’s own risk management needs.

The successful candidate for the Sr. Service Engineer (Information Security Consultant) role will engage in a consulting role with both internal clients and Microsoft’s public sector and enterprise customers to asses, develop and architect Microsoft infrastructure security solutions, specifically focused on the areas of public key infrastructure, Active Directory, certificate management and enterprise network security assessments. A thorough understanding of Microsoft technologies and experience deploying complex enterprise solutions will be valuable experience for the right candidate.

Senior Service Engineer (Information Security) responsibilities:

Develop, design, and architect technical infrastructure security solutions, including the design and architecture of enterprise
Windows PKI environments, the assessment of Microsoft Active Directory environments, deliver enterprise vulnerability scanning and leverage a thorough understanding of related technologies.
Perform extensive technical consulting in the areas of infrastructure security focused on Microsoft technologies such as AD, LDAP, Windows PKI, SharePoint, Forefront TMG & UAG
Follow all Microsoft services delivery methodology for external engagements, including ACE specific requirements around utilization, quality assurance, consistent delivery and meeting a high bar for customer satisfaction
Geographic scope is the Americas however may require overseas travel. Very extensive travel is a requirement with most deliveries requiring onsite presence within the continental United States
Must be able to work autonomously as well as in team environments, often in stressful, high impact situations

Requirements/Qualifications and Previous Work and Related Experience:

Advanced knowledge of TCP/IP, Kerberos, PKI, AD, Windows Networking in the enterprise environment is required
Excellent written, verbal and presentation skills are required
Strong analytical and organizational skills are essential and required
5+ years’ experience conducting enterprise infrastructure security assessments, designing, deploying infrastructure security solutions required
An understanding of ISO27002 standards and related assessment methodologies is desired
CISSP, SANS certifications, Microsoft technology certifications and other security certifications are desired

To apply, click here.

Technical Dependency Analysis

ACE Team — Fri, 19 Feb 2010 19:37:26 GMT

Hi, I’m Kevin Harris, Principal Program Manager with Microsoft’s Enterprise Business Continuity Management (EBCM) team. This blog entry accompanies my video on a key component of our business continuity methodology – the Technical Dependency Analysis or TDA.

The Business Impact Analysis (covered in an earlier blog and video) is our process driven engagement point that provides both an evaluation process criticality, using a standardized list of criteria to qualify and quantity the risk of an unexpected disruption. We engage directly with each business unit to document the anticipated impacts, which then substantiate the recovery goals for that process (in terms of recovery time objectives and recovery point objectives). Our implementation at Microsoft prioritizes those business processes that meet the company’s criticality standards. These “critical” processes then undergo a dependency analysis that includes non-technical items (such as people, internal or external dependencies) as well as technical dependencies (such as Line of Business applications, middleware, infrastructure, etc.).

For each technical dependency that the business identifies as essential for recovery, we conduct a detailed technical dependency analysis (TDA). The TDA is important because each application identified by the business is really a complex web of technical dependencies, which usually have additional technical components, secondary and/or tertiary dependencies that the business is unaware of but are essential to recovery of the Line of Business application. Without this important TDA phase, some technical dependencies that are working “behind the scenes” may be missed, which could prevent recovery of that particular business process or function.

The TDA is critical to the successful implementation of a business recovery strategy. Each layer of each technical component needs to have its own recovery time objective that allows the successive layers ample time to recover and still meet the overall process recovery time objective (RTO). The TDA also assists us with identifying single points of failure and tracking critical technical assets.

As I mention in the video, the TDA provides an “end-to-end” mapping or a blueprint of a technical environment. This information helps business continuity or disaster recovery teams to:

Understand the current recovery capability of a technical dependency
Create strategies that take all aspects of technical recovery into account
Gain insight into capacity planning for shared infrastructure elements.

In addition to BCM, the data collected during the TDA has benefits that extend well beyond a BCM program. For example, periodic review of an “end-to-end” process can result in process and quality optimization. These technical “blueprints” provide holistic views for enabling effective service management, managing a service catalog, as well as modeling opportunities for new architecture designs or system deployments. Organizations can also use this information to plan for or evaluate risks associated with a specific element of infrastructure as I mention in the video with the data center example. The information asset from the TDA also helps crisis management teams understand business impact of threats (e.g. flood impacts to a data center).

Our broader vision is to build an information asset that provides value to and is maintained by a broad stakeholder community. One of the single most important best practices associated with any BCM program is keeping the data and plans current; the TDA is no exception, so it is important that refreshes of the data occur regularly. Organizational discipline with Change Management practices and BCM maintenance policies are essential to ensuring the information stays relevant and disaster recovery capabilities meet stakeholder expectations.

-Kevin Harris
Principal Program Manager, Enterprise Business Continuity
Microsoft Information Security

Using the Business Impact Analysis

ACE Team — Tue, 26 Jan 2010 16:53:00 GMT

Hi all, I’m Tom Easthope, Sr. Program Manager on the Enterprise Business Continuity team at Microsoft. This blog entry is a companion to the video interview about a key component of our business continuity methodology – the Business Impact Assessment or BIA.

The BIA is a foundation tool in BCM program as it provides both qualitative and quantitative measures of impact to a company in the event of a business process disruption. The BIA is a key component of a BCM program as it creates a more holistic or “business driven” perspective which differentiates business continuity from the more IT centric disaster recovery processes. The BIA also creates an enterprise wide standard or common taxonomy across business units which help to align cross organizational collaboration activities as well facilitate reporting at an enterprise level.

At Microsoft, the BIA understandably is a key engagement point for our BCM program. Each BIA session is facilitated by a certified professional in our enterprise program office or in one of the “embedded” teams in our business units. Our BIA evaluates criticality along two dimensions:

1. Time

2. Impact across six categories: (Revenue, Customer Partner/Experience, 3^rd Parties, Legal/Regulatory, Workforce and Brand/Shareholder)

The BIA and the larger BCM program are aided at Microsoft by several governance organizations that provide leadership on setting enterprise wide standards to providing feedback on the company implementation of the BIA. These groups provide organizational credibility; reflect ongoing commitment and accountability of results – all key criteria for any successful enterprise program.

One less obvious benefit of the BIA is that it serves as a great business justification tool. For example, in resource constrained situations such as the current economic environment, the BIA can be a great tool to align investment priorities with those organizational functions that are most critical to the business and its stakeholders.

For this reason it is important to keep BIA assessments current. The pace of business is accelerating and today’s emerging products or functions can quickly become tomorrow’s category leading product or primary cost cutting strategy. Only a current BIA can fundamentally integrate these emerging areas into the mainstream of a business continuity program and deliver on the organizational resiliency expectations of our customers and stakeholders.

In our next blog posting we’ll spend some time on the Technical Dependency Analysis function in our EBCM program that will compliment, my colleague, Kevin Harris’s video on the subject.

-Tom Easthope

Senior Program Manager, Enterprise Business Continuity

Microsoft Information Security

Simple Rules To Stop Bad Guys

TheRockyH — Wed, 16 Dec 2009 09:46:00 GMT

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: <script>alert('XSS Bug')</script> 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

ACE Team — Tue, 01 Dec 2009 01:24:00 GMT

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

ACE Team — Mon, 16 Nov 2009 21:49:00 GMT

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:

-Diane Talvo
Microsoft Information Security

Dogfooding: How Microsoft IT Information Security Dogfoods: Product Influence

ACE Team — Sat, 31 Oct 2009 00:40:00 GMT

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

ACE Team — Mon, 26 Oct 2009 18:03:00 GMT

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^TMfeature. An industry trend is the explosion of removable media used in the enterprise. We prescribed Windows 7 BitLocker to Go^TMas 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.

-Price Oden
Principal Senior Security Architect
Microsoft Information Security

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

ACE Team — Mon, 19 Oct 2009 20:31:00 GMT

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

ACE Team — Thu, 15 Oct 2009 21:19:00 GMT

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

ACE Team — Fri, 09 Oct 2009 02:51:00 GMT

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

ACE Team — Thu, 01 Oct 2009 01:36:00 GMT

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 the 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

ACE Team — Tue, 29 Sep 2009 23:46:00 GMT

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

ACE Team — Mon, 28 Sep 2009 06:30:00 GMT

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.

Load Pattern	Step
Initial User Count	10
Maximum User Count	500
Step Duration (seconds)	20
Step Ramp Time (seconds)	0
Step User Count	10

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!

ACE Team — Thu, 17 Sep 2009 23:53:00 GMT

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

ACE Team — Wed, 16 Sep 2009 21:34:00 GMT

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

ACE Team — Tue, 11 Aug 2009 02:11:00 GMT

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:

-Anmol Malhotra
Senior Security Engineer
ACE Team

Video Series: ACE Security Consultants from the Field

ACE Team — Tue, 04 Aug 2009 23:45:00 GMT

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.

More videos coming up from ACE security consultants in the field, stay tuned...

-Diane Talvo
Security Awareness Program Manager
Microsoft Information Security

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

ACE Team — Thu, 30 Jul 2009 00:43:00 GMT

Hello, Anmol here…continuing our discussion of Security Development Lifecycle for Line-of-Business applications (SDL-LOB) process, let’s discuss Phase Four: Verification for LOB today. The SDL-LOB defines the standards and best practices for providing security and privacy for new and existing line-of-business (LOB) applications currently under development or being planned for development. If you missed prior phases, read them here: Phase One, Phase Two and Phase Three.

Phase 4 is all about verifying different security claims made in earlier phases and identifying gaps in implementation. For example, during design review phase, let’s assume an application team identifies that the design is vulnerable to cross site scripting attacks and therefore adds security requirements such as AntiXSS library to be incorporated during coding. During the verification phase, a security SME (subject matter experts) will verify that all user controlled data which needed to be validated and encoded is actually *done*. If there are any gaps identified, they will be triggered as security bugs for the application teams to fix.

Here are a few key tasks to be executed in this phase:

Conduct pre-production assessment (white box/black box reviews, deployment reviews of servers & privacy reviews)
Identify security issues and applying a severity rating.
Compliance: Tracking all risks identified.

Before a line-of-business (LOB) application is deployed in production, the application must adhere to internal security policies, guidance and follow industry best practice. As mentioned above, in this phase expert application security SMEs are engaged. One way a SME verifies an application is by performing a pre-production assessment. What’s a pre-production assessment? It’s an assessment performed based on the service level assigned depending on the application’s risk rating. Back in “Phase 1: Requirements for LOB” a Risk Assessment was conducted which determines an application’s risk level. Based on the risk level, a service level is then assigned. Generally white box code review is conducted on applications that are medium or high risk rating. An ideal comprehensive assessment will be a combination of white and black box testing. Having said this, performing the assessment with a mix of manual process automated tools can help save some time. For code reviews (white box) testing, a SME will identify categories of vulnerabilities in the code. Here are some vulnerabilities that are identified:

SQL injection. Ensure that the SQL queries are parameterized (preferably within a stored procedure) and that any input used in a SQL query is validated.
Cross-site scripting. Ensure that user controlled data is encoded properly before rendering to the browser. .NET applications can leverage Anti-XSS library for encoding data that is more rigorous than the native .NET encoding.
Cross-site request forgery. Ensure that the Page.ViewStateUserKey property is set to a unique value that prevents one-click attacks on your application from malicious users.
Data access. Look for improper storage of database connection strings and proper use of authentication to the database.
Input/data validation. Look for client-side validation that is not backed by server-side validation, poor validation techniques, and reliance on file names or other insecure mechanisms to make security decisions.

See the complete list of vulnerabilities and learn more about verification in this Phase 4. Watch the podcast called “SDL-LOB Phase Three: Implementation” where Eugene Siu, Senior Security Engineer of Microsoft ACE Team, provides an overview of code reviews and more.

Next time I’ll discuss Phase 5: Release for LOB. Till then happy & secure coding.

-Anmol Malhotra
Senior Security Engineer
ACE Team

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

ACE Team — Mon, 13 Jul 2009 19:49:00 GMT

Hello, Anmol here. For this blog series I’ll discuss the the Security Development Lifecycle for Line-of-Business applications (SDL-LOB) process and covering all 5 phases. Today I’ll discuss Phase Three: Implementation for LOB. The SDL-LOB defines the standards and best practices for providing security and privacy for new and existing line-of-business (LOB) applications currently under development or being planned for development. If you missed prior phases, here’s Phase 1 and Phase 2.

Highlight for phase three are:

· Incorporate Security Checklist and Review Policies

· Conduct ‘Self’ Code Review

· Run Code Analysis Tools and Incorporate Security Libraries

You may be wondering, what is a ‘self’ review? A ‘self’ review involves assessing your application to ensure it complies with security checklists and standards; and conducting a self-directed code review and code analysis of the application. An internal review is performed by the application development team. It’s important for development teams to adopt coding techniques and methodologies. More importantly, the next step is to incorporate documented coding practices and forming a security checklist. A checklist creates a threshold for you to measure against, i.e., at minimum these items must be met. Using a security checklist is not a new concept; however ensuring items not met on the checklist are sufficiently documented and accounted for is the key to its effectiveness. See checklist items from the Security Checklist Index from Microsoft Patterns and Practices. In this phase, development teams also conduct an independent “self” code review. To perform this task, there are several available security tools Microsoft offers including static analysis, runtime security tools and libraries. The Anti-XSS library can protect ASP.NET Web-based applications from XSS (cross-site scripting) attacks. It offers a more rigorous “white-list” approach than the native encoding methods found in .NET. Run CAT.NET on managed code (C#, Visual Basic .NET, J#) applications. CAT.NET is a snap-in to the Visual Studio IDE that helps you identify exploitable code paths for security vulnerabilities, such as XSS, SQL Injection, Process Command Injection and more. Get familiar with the SDL-LOB document and learn more about available tools and additional details on how to perform internal reviews for your application.

Next time I’ll discuss Phase Four: Verification for LOB. Till then happy & secure coding.

-Anmol Malhotra
Senior Security Engineer
ACE Team

Blog Series: Get Familiar with the SDL-LOB Process, Introduction to Phase Two: Design for LOB

ACE Team — Sat, 20 Jun 2009 04:29:00 GMT

Hello, Anmol here. This is a continuation of my blog series on the SDL-LOB process. In my last blog entry I talked about Phase 1: Requirements for LOB. Let’s discuss Phase Two: Design for LOB. As you read my blog series on the SDL-LOB process, I will try to share experiences and lessons learned from an Information Security group perspective.

Phase Two is all about ensuring that application follows “Secure by Default” principle.

There are 2 key tasks to be executed in this phase:

· Threat Modeling

· Design Review

Both of these activities are aimed towards identifying security design flaws upfront in the lifecycle and helping in reducing the number of security bugs propagating on to the next stages. It is far more resource intensive and cumbersome to mitigate issues identified during verification phase and even costlier if identified in production time. Let me illustrate this by an example shown below:

Let’s assume that your design did not consider validating user controlled input and output encoding strategy. This would result in developers coding and developing the application without deviating from the final design which lacked specific security considerations in the first place. This would eventually result in 100s of “Cross Site Scripting” bugs turning up during verification stage. I am sure no application team would want that to happen. Wouldn’t it be nice if we followed few design time activities which would call out specific security considerations that need to be followed by the development team in the context of the application?

To learn more read the detailed Design phase tasks here and also watch my podcast "Security Design Reviews" where I discuss more why security should be "baked" into the application starting with the Design phase. Next time, I’ll talk about Phase Three: Implementation for LOB.

Here are some additional resources

-Anmol Malhotra
Senior Security Engineer
ACE Team

Blog Series: Get Familiar with the SDL-LOB Process, Introduction to Phase One: Requirements for LOB

ACE Team — Tue, 16 Jun 2009 20:00:00 GMT

Hello, Anmol here. For this blog series I’ll discuss the SDL-LOB process and cover all 5 phases as we go. In my last blog entry I provided an overview of this process, Blog Series: Get Familiar with the SDL-LOB Process. Today I’ll discuss Phase One: Requirements for LOB. As you read my blog series on the SDL-LOB process, I will try to share experiences and lessons learned from an information security group perspective.

Phase One: It’s is all about “Risk Assessment”

What we learned from our experiences working for more than 6 years now in securing Microsoft’s line of business applications is that effectively assessing risk is one of the stepping stones for managing a big portfolio of applications in an enterprise. We have an inventory of more than 3500 applications which have different security and privacy needs. As you can imagine, it would have been impossible to manage such a large number of applications without effective –

a) Application inventory

b) Risk Assessment

c) Service Levels

The following diagram summarizes key tasks in this phase:

Every organization is unique in how it measures and reacts to risk. However under the hood the basic principle for assessing risk remains consistent. When looking at application we first try to gather the following information.

a) Data: Type of data being handled by the application (is it sensitive, non sensitive, public, etc.)

b) Business: Business Unit being catered by the application (such as finance, HR, payroll or cafeteria)

c) Audience: Audience (users of the application) and hosting type (internal/external)

From a broader level, we are also trying to get a mind map of what will be the impact on the organization if the application got compromised.

a) Will this cause negative impact to the company’s reputation? (loss of customers, brand, etc.)

b) Will this cause negative business impact? (loss of revenue, sensitive data stolen, etc.)

As application data becomes more sensitive or the system becomes more critical to business, risk increases.

Whenever you’re working with risk, it’s most likely there will be a risk assessment in some form conducted. For the SDL-LOB process, a Risk Assessment questionnaire helps us capture general security and privacy ‘‘qualities” for the application. This allows us to determine the appropriate amount of “oversight” needed. Essentially we are trying to understand the potential risk the application poses for the enterprise. From a risk perspective, if an application is high risk, we’ll put forth more oversight and vice versa, if an application is low risk, it receives less oversight. Note that definition of what is “High” is also organization specific. You can create your own risk categories such as “Red/Orange/Green,” “High/Medium/Low,“ “Most Risky/Risky/Minimum Risk” - it’s all up to you. Identifying the most risky applications in an organization and spending the right resources, money and time to reduce the risk posed by them is the key here.

At Microsoft, risk assessment produces repeatable guidance on the type of oversight the application will receive in the SDL-LOB process. I encourage you to read the detailed requirements and recommendations for this Phase on Security Development Lifecycle 4.1 under SDL-LOB section.

Next time I'll talk about Phase Two: Design for LOB.

-Anmol Malhotra
Senior Security Engineer
ACE Team

Blog Series: Get Familiar with the SDL-LOB (Security Development Lifecycle for Line-Of-Business Applications) Process

ACE Team — Tue, 02 Jun 2009 18:14:00 GMT

Hello, Anmol Malhotra here. I’m a Senior Security Engineer with ACE Team, a part of Microsoft IT Information Security group. I’d like to introduce you to the Security Development Lifecycle for Line-of-Business Applications (SDL-LOB) process.

As part of our continued commitment towards sharing security processes and recommendations with our customers, we’re excited to announce the addition of detailed security requirements and recommendations for LOB (line-of-business) applications with the release of Microsoft SDL version 4.1 on MSDN.

SDL-LOB provides a mainstream approach to the SDL which focuses on development of applications that support the business such as accounting, human resources (HR), payroll, supply chain management and resource planning applications, etc. The SDL-LOB guidance is positioned exclusively for LOB applications or web applications; and not for ISV/rich client and server application development.

Here’s an overview of SDL-LOB process. High level tasks performed in each stage are listed in the table below:

Training

Requirements

Design

Implementation

Verification

Release

LOB-specific training

Risk assessment

-Application portfolio

-Application risk assessment

-Determine service level

Asset-centric threat modeling

-Threat model

-Design review

Internal review

-Incorporate security checklists and standards

-Conduct “self” code review

-Security code analysis

Pre-production assessment

-Comprehensive security assessment

-Bug tracking

Post-production assessment

-Host level scan

It is important to note that organizations should adapt rather than adopt “Microsoft SDL-LOB” process. Organizations are unique – given that fact we should expect and plan for differences in resources, executive support and security expertise.

Some of the highlights of SDL-LOB are:

To weave security in SDLC by embedding various milestones/checkpoints in each of the phases.
Identifying security vulnerabilities early in the development cycle and thereby improving the overall design.
To enable effective application risk management from strategic, tactical, operational and legal perspective.

At Microsoft, all line-of-business application development teams must go through the SDL-LOB process and if they fail to do so, the application cannot go live. Enforcement of the SDL-LOB process attributes to its success.

In this blog series I’ll discuss the highlights of each of the phases in SDL-LOB. Next time, I’ll go over Phase 1: Risk Assessment for LOB. In the mean time get familiar with the SDL-LOB here.

-Anmol Malhotra
Senior Security Engineer
ACE Team

How Do I: Set Up Fiddler’s Reverse Proxy to Create a VSTS 2008 Web Test

ACE Team — Sat, 30 May 2009 02:10:00 GMT

VSTS 2008 has a great recording tool that allows you to create web test simply by recording your web traffic in the browser. But what if your application doesn’t use web browser, but still communicates with servers using HTTP or HTTPS protocols (such as Smart Client application). Then, you can use Fiddler to capture web traffic on the client side and create a VSTS test from Fiddler’s capture. Unfortunately, there might be one more problem… Since Fiddler acts as a proxy, you web application’s traffic has to go through Fiddler. But it doesn’t work for some application, which might have web server name hardcoded into code or configuration file. When this happens, there is another way to record application’s web traffic and create a VSTS 2008 web test – by using Fiddler’s reverse proxy. By reverse proxy I mean capturing web traffic on the web server side, and not on the client side. Basically, your application will think that it’s hitting web server, while it will be directing its traffic to Fiddler installed on web server, and then Fiddler will forward that traffic to the actual application.

Here are the steps on how to set up and use reverse proxy:

1. Log in to your web server and install the latest versions of Fiddler (http://www.fiddler2.com/Fiddler2/) and neXpert (http://www.fiddler2.com/fiddler2/addons/nexpert.asp)

2. Open IIS manager (Start>Administrative Tools>Internet Information Services (IIS) Manager)

3. Find your application under Web Sites, right click it and select Properties

4. Change TCP port from 80 to 81, and click OK

5. Open Fiddler on Web server

6. Select Tools > Fiddler Options

7. Make sure “Allow remote computers to connect” check box is checked on General tab

8. Click on Connections tab, and Change “Fiddler listens on port:” from 8888 to 80, and click OK

9. Select Rules > Customize Rules…

10. Find “static function OnBeforeRequest(oSession: Session)”

11. Add the following code inside of curly brackets: if (oSession.host.toLowerCase() == "webserver") oSession.host = "webserver:81"; //(where webserver is the name of your web server, make sure you spell it in lower case)

So, it should look like this:

static function OnBeforeRequest(oSession: Session)

{

if (oSession.host.toLowerCase() == "WebServer") oSession.host = "WebServer:81";

12. Save it and close text editor.

13. Close Fiddler and open it again.

14. Make sure that Fiddler is capturing the traffic (Left bottom corner should say “Capturing” or if you click on File menu, “Capture traffic” will have a check mark next to it)

15. Open the application you want to record on the client (not on web server) and perform activities you want to be recorded.

16. Make sure to add a step description after each step you perform by going back to Fiddler on Web server, selecting neXpert tab and clicking Add for Step Description.

17. After you recorded all steps, go back to Fiddler on Web server and stop capturing.

18. Select all recorded sessions (Ctrl + A), right click them and select Save>Selected Sessions>as Visual Studio Web Test…

19. Also, make sure to check out neXpert report, by clicking Create Report button on neXpert tab.

20. Change Fiddler listen port back to 8888 (Tools > Fiddler Options > Connections tab). And close fiddler

21. Change application’s TCP port back to 80 in IIS manager (See step 4)

22. Then, copy the Web test you created with Fiddler in step 18 to your machine (Where you have VSTS 2008 installed).

23. Open or Create a VSTS 2008 test project.

24. Right click Project name in Solution Explorer and select Add > Existing Item. Browse to your recorded web test and click OK.

25. Open web test from Solution Explorer and remove “:81” from all requests (by pressing CTRL + H, and replacing all “webserver:81” with “webserver”, where webserver is the name of your Web server)

26. Then, save the Web test and run it.

Notice that web test has transactions already for each step that you recorded, if you added step description using neXpert tab.

Also, this method works the best for http traffic. If your application uses https, you can disable it while recording the test, by:

- opening IIS manager on the web server

- right clicking your web site and selecting Properties

- selecting Directory Security tab

- clicking Edit on Secure Communications session

- and unchecking “Require secure channel (SSL)”

Make sure to switch it back on when you done recording the test and replacing all HTTP requests in your Web test with HTTPS (the same method we used in step 25).

I also created a video on how to set up a Reverse proxy. You can view it here: http://msdn.microsoft.com/en-us/teamsystem/dd876614.aspx

----------------------------------------

Vitaliy Konev

Performance Engineer

Microsoft – ACE Team

TechNet Webcast: Configuring with Least Privilege in SQL Server 2008 (Level 300)

ACE Team — Sat, 30 May 2009 00:46:00 GMT

TechNet Webcast: Configuring with Least Privilege in SQL Server 2008 (Level 300)

Tuesday, June 02, 2009 8:00 AM Pacific Time (US & Canada)

Presenter: Varun Sharma, Security Engineer, Microsoft Corporation

Overview:

With SQL injection attacks on the rise, it is imperative to configure Microsoft SQL Server with least privilege. In this webcast, we provide an overview on how to configure a SQL Server installation with least privilege for a typical line-of-business application. We cover configuring least-privileged service accounts for SQL Server services, best practices for configuring least-privileged principals used by the front-end or middle tiers to connect to the SQL Server back end, and the details of configuring SQL Server job steps with least privilege.