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. 

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

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

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.

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

• 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

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

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.

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

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