ACE Team - Security, Performance & Privacy

Dogfooding: How Microsoft IT Information Security Dogfoods: Product Influence

2009-10-31T00:40:00Z

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

2009-10-26T18:03:00Z

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

2009-10-19T20:31:00Z

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

2009-10-15T21:19:00Z

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

2009-10-09T02:51:00Z

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

2009-10-01T01:36:00Z

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

-Diane Talvo
Security Awareness Program Manager
Microsoft Information Security

Risk Tracker v1.0 Release

2009-09-29T23:46:00Z

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

2009-09-28T06:30:00Z

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!

2009-09-17T23:53:00Z

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

2009-09-16T21:34:00Z

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

2009-08-11T02:11:00Z

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

2009-08-04T23:45:00Z

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

2009-07-30T00:43:00Z

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.

2009-07-13T19:49:00Z

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

2009-06-20T04:29:00Z

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