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 2: 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 2 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 3: Implementation for LOB.
Here are some additional resources
-Anmol Malhotra
Senior Security Engineer
ACE Team
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 1: 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 1: 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 2: Design for LOB.
-Anmol Malhotra
Senior Security Engineer
ACE Team
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:
.png)
| 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
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)
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.
Register Here
TechNet Webcast: Fundamentals of Third-Party Security Management (Level 300)
Monday, June 01, 2009 10:00 AM Pacific Time (US & Canada)
Presenter: Gerard Morisseau, Senior Program Manager, Microsoft Corporation
Overview:
In this webcast, learn the fundamentals for building a vendor security management program that provides reasonable assurance that third parties who are hosting and managing your data, applications, or business processes have appropriate levels of security controls in place to protect your information assets.
Register Here
Hello Everyone!
My name is Shawn Rabourn and I am a Senior Security Consultant with ACE (Assessment, Consulting and Engineering) Services, a part Microsoft IT's Information Security (InfoSec) group. Sounds like a mouthful, I know. Really, that is just my title. I have a unique position within Microsoft where I can offer Security Guidance to internal Microsoft employees who are planning to make infrastructure changes. I also have two customers external to Microsoft that I offer consulting services to. ACE Services’ offers consulting services, leveraging Microsoft IT (MSIT) internal processes and best practices to deliver a specialized product to our customers.
My responsibility to InfoSec is to perform Security Design Reviews (SDR) and Security Design Consulting (SDC). If there is a change to the core infrastructure of Microsoft, in most cases it is subject to the SDR process. We receive the details of the change and we assess the change against our published security policies, Microsoft internal policies and the industry best practices. Once we diagnose the proposed change in the SDR, the person submitting the proposed change is strictly held to the recommendations set forth in the SDR. The SDC process differs from the SDR process in that the submitting employee is unsure of what kind of infrastructure change they may need to accomplish their end goal. We can give them the baseline security guidelines to comply with policy or we can even go deeper to recommend specific configuration of servers, applications and/or hardware. If the person submitting an SDC decides to follow through to achieve their end goal, they are still subject to an SDR.
Through SDRs and SDCs I’ve been able to work with a wide range of internal customers in many different organizations and business groups. In every SDR or SDC, I have a responsibility to protect Microsoft assets, intellectual property, employees and customers. Each request, however different, lends itself to similar lines of questioning. Are we moving or storing Personally Identifiable Information (PII)? Are we moving or storing customer data? Are we making something externally accessible? What are the perceived risks? What is being done beforehand to mitigate these risks? In some cases, the design submitted is mostly compliant with policy and poses little risk to our infrastructure. In others, our guidelines may be nearly impossible to follow and the design need be reconsidered.
As SDRs typically do not discriminate between technologies, in the field my work is highly specialized and product-centric. I’ve spent nearly 8 years at Microsoft working with customers in different capacities from Product Support Services to Premier Field Engineering and now ACE Services Consulting and what I have found is that the higher up the technology stack you go, the attention to other details has a tendency to go down. I have been guilty of this as well. The simple fact that you can’t write a line of code, schedule a task, set a registry value or check a checkbox to address all problems is a hard barrier to climb over. What becomes lost in technical detail usually becomes the infamous “gotcha” that delays a project schedule. A company’s IT security policies may not be taken into consideration in an engineering design and often it is too late in the project before the important questions are asked.
One of my specialties is Forefront Identity Manager (FIM) and its predecessors Identity Lifecycle Manager (ILM), Identity Integration Server (MIIS). One of the functions of FIM is to take unique, unrelated data sources with identity data, often authenticating data and initiate and maintain synchronization between these sources. This ensures identity data consistency. The engineering logistics behind connecting unique sources of data typically involve network connectivity and attribute formatting. Beyond that, we may also incorporate timing to ensure we access and change data at appropriate intervals. My experience in the SDR process leads me to think about some of the other logistics as well. How sensitive is the PII we are synchronizing? What is the company policy regarding storage or encryption of PII? Is there anything defined in policy with regard to encryption strength or algorithms used? What logic do we need to incorporate to ensure that employee data is handled appropriately per policy in the case of a termination? Is the data source externally accessible and if so, what are the policies around data that can be viewed externally? Is there a firewall between the datacenter housing the FIM server and the connected sources? What are the guidelines for creating and maintaining an account that has permission to read and write identity data? These questions, left unanswered can (and have been known to) cause delay in an overall project.
As you can see, the SDR process is a very important step in protecting Microsoft’s overall infrastructure and as you can imagine, those who incorporate the SDR process in their project planning find more success in meeting their milestones. I encourage any consultant or project manager to investigate their company’s equivalent to our SDR process early in a project and if there is not a process in place, take steps to review your project against your company’s IT security policies and industry security best practices. Allocate a small amount of time early in the project or risk spending a large amount of time late in the project. Feel free to contact us and provide comments, feedback.
Good Luck!
-Shawn W. Rabourn
Senior Security Consultant
ACE Services
This is Rob Cooper, Senior Engineer for ACE Infrastructure (also known internally as ICE for you William Gibson fans). Thanks to Irfan Chaudhry, Director of the ACE Team, for giving us a good overview and history of ACE and how ACE’s role has expanded over the years. I’m with ACE Infrastructure (also known as ICE). Our role is to focus on the implementation of technology. It may be an internal LOB (line of business) application, a third-party product or new hardware or network appliances. Mergers and Acquisitions are one of our responsibilities. Although our role is diverse, most functions can be described by a small number of services. On our team, reviews are divided into Security Consultation Reviews, Security Design Reviews and Security Compliance Reviews.
Security Consultation Reviews are when a project team asks us for advice on how to proceed, while they’re still in the design and development stages. Consultation Reviews are optional, but extremely helpful.
Security Design Reviews are for a project that has a complete (or nearly complete) design and is ready to release. Obviously, Security Design Reviews are simplified if a project has completed a Security Consultation Review. Mitigation steps and design changes are likewise much easier while the project is still in the design phase. Can a design change between the Consultation Review and a Design Review? Certainly, but the Consultation Review helps guide the project, and helps the infrastructure team get early visibility into the project and creates an early relationship with the project team, both of which help considerably.
Security Compliance Reviews are scheduled for a reasonable timeframe after project implementation. This varies, but most projects can be reviewed within 60 days of deployment. Larger projects may require more time, or have multiple reviews for individual subcomponents. Security Compliance Reviews verify that identified risks and proposed mitigation steps from the Design Review have been implemented.
ACE Infrastructure then has a very practical role tied to which decisions are made about how a deployment is configured and when a deployment occurs. This is different than an application review, which analyzes all possible configurations. Let’s take IIS as an example. An application review focused on authentication may look at all authentication methods, from certificate authentication all the way down to clear-text credentials. The application review is to ensure the highest level of encryption is available to IT professionals and other IIS customers. An infrastructure review is focused on a particular deployment, so reviewing authentication might determine which methods of authentication may be used and which must not be used.
Over the next several months (and hopefully beyond), I will be providing a particular view into some of the tools we use, many of which are developer-focused tools (including the Microsoft Threat Analysis & Modeling Tool). Other approaches come from years of experience of infrastructure deployments. It is our intention to share how we use existing tools, how we leverage previous work and experience and the most effective way to increase security during implementation. Please look for the following:
· Examples of known change types, including how to leverage these for an expedited workflow.
· Explanations and descriptions of well-settled policies that can help you understand why these policies are in place, and well-known alternatives that can be both effective and secure.
· How to leverage development tools (primarily the Microsoft Threat Analysis & Modeling Tool), including templates, examples and flowcharts that help us to help you.
Security infrastructure services at Microsoft are both exciting and challenging. We typically work with pre-released products and we can assist in making these products more secure. In future posts I hope to share how early engagement of our services can help your product in the long run. As a paranoid security engineer I might not provide specific implementation details, but I do hope to tell you some stories from the trenches that show how we can help.
Watch my podcast “Infrastructure Security Engineering” as I discuss how we try to balance security between the application and infrastructure side.
Thank you and I look forward to sharing these with you in the future and in hearing your feedback.
-Rob Cooper
Senior Engineer
ACE Team – Infrastructure Security
When I first joined Microsoft IT, I was intrigued by the concept of offering security assessment as an optional service to the business. I was even more surprised to see how enthusiastically the business had embraced the concept. You see, like many security professionals, I came from an organization where information security was widely perceived as obstructionists and a tax to the business.
I would later discover that offering IT security assessment services to internal business is a constant balancing act, whose success hinges on the ability of IT to demonstrate and deliver real value to the business, while helping the enterprise reduce risks and improve its overall posture. Today, I will explore some of the issues you can expect to face when offering security assessment services to internal customers.
Striking the right balance between securing information assets and business objectives should be at the core of the service and drive the engagement and delivery model. This balance is all the more important here at Microsoft, where a culture of innovation and entrepreneurship often creates healthy frictions between the development community and information security. The former driven by customer demands for more features and deployment flexibility, the latter bent on enforcing security policies and closing holes. These frictions often lead to creative solutions and expose new case scenarios. A clear benefit, only if the interaction between the business and IT is orchestrated properly through a set of services that recognize the needs of both parties and can provide meaningful feedback.
The key in addressing this problem is to provide services that capture, address and drive the focus on security throughout the System Development Life Cycle. These services should include design consultation, pre and post deployment reviews, and operational assessment and compliance. Other offerings should be aligned with key business processes such as procurement, fulfillment, supply chain management, etc.
Security service should also be able to strike a balance between servicing the specific security needs of individual business unit versus those of the larger enterprise. For example, a client might want to remove antivirus software from its servers to improve application performance or refuse to migrate from a legacy and unsupported application. While these requests might have legitimate business justifications, they run counter to what it takes to secure the enterprise. Another manifestation of this problem can be during the process of prioritizing risks and allocating remediation resources.
Essential to the ability to deliver security as a service is to ensure that the organization has established security policies and a risk framework that provides a consistent way to manage risks (i.e. identify, assess, measure, prioritize) across the enterprise.
-Gerard Morisseau
Senior Program Manager
ACE Team – Infrastructure Security
This is Gerard Morisseau, Senior Program Manager for ACE’s Information Security Assessment Services (ISAS). ISAS offers several security assessment services aimed at helping Microsoft IT and the business assess their information security risks, improve controls environment, and strengthen their information security management systems. Our most popular services include Information Security Risk Assessment, Controls Assessment Training and Vendor Security Maturity Assessment. These services are based on the ISO/IEC 27002:2005 standard, an internationally recognized framework for managing information security management programs.
The Information Security Risk Assessment service is designed to help organizations identify, evaluate and prioritize risks to their critical information assets. The service also helps organizations develop remediation plan based on risk prioritization model. The goal of this service is to ensure that clients are managing their information assets in a manner not only consistent with Microsoft security policies and standards, but also with industry best practices.
The Vendor Security Maturity Assessment provides managers with great insights into third parties’ ability to secure and maintain the confidentiality, integrity and availability of hosted information assets. This service also helps ensure that third parties are managing information assets in a manner not only consistent with established security policies and standards, but also with industry best practices.
These services are now available to Microsoft customers and partners interested in assessing information security risks in their environment or at third parties hosting their information assets.
ISAS also include services to help prepare organizations interesting in obtaining their ISO 27001 Certification.
Watch my podcast “Infrastructure Security Assessments” where I describe our risk models and I also talk about how we how identify security maturity levels in different environments inside and outside of Microsoft. Feel free to contact us if you have any questions or comments.
-Gerard Morisseau
Senior Program Manager
ACE Team - Infrastructure Security
My colleague & A.C.E. performance engineer Chris Lundquist has compiled a 6:58 wmv featuring his unscripted yet eloquent dialog walking us step-by-step through a VSTS web test:
- Starting VSTS
- Adding a new C#/Web Test project
- Adding comments
- Running the test, exploring the Web Browser, Request, Response, Context, & Details tabs
- Modifying test parameters & re-running
This is the best introduction to this technology you may ever see. It's certainly the best I've seen.
Read more...
Jimmy May, MCDBA, MCSE, MCITP: DBA + DB Dev
Senior Performance Consultant: SQL Server
A.C.E.: Assessment, Consulting, & Engineering Services
http://blogs.msdn.com/jimmymay
"If it is fast and ugly, they will use it and curse you; if it is slow, they will not use it."
—Computer science professor, billionaire, & entrepreneur David Cheriton
An all too familiar scene repeated itself two weeks ago. My good friend & CISO of a mid-sized technology company, lets call him Alok, went into a budget planning meeting and came out as a shadow of his former self. To be more precise a 85% version of the Alok that I know. He had just been handed a 15% reduction in budget.
Like most managers, Alok, started taking stock of his mini-empire and prioritizing things that he could do without. Luckily he had already expected a cut and so had planned ahead. Unluckily, he had planned for a 6% reduction not a 15% reduction. After some brainstorming and taking some tough decisions he had cut costs by 10%. Now began his quest for the elusive final 5%. His organization had started the transition from being a network security centric organization to a more application security centric organization around 15 months ago. So, a solution posed by one of his managers was to drop the security engineering process integration program and replace it with a set of static analysis tools they had just evaluated. This strategy had paid of handsomely for them in the network security field. Ron, one of the leading application architects in the organization was opposed to the idea. Thus started a turf war, which left some angry, most frustrated and everyone confused.
Unlike most managers, Alok reached out for advice. Read more…
- Akshay Aggarwal
Hi, my name is Brad Gobble and I manage ACE’s Infrastructure Security Team, a part Microsoft IT’s Information Security group. Over the next few weeks you’ll hear a lot about our services: what we do, how we do it, how we prepare our team to execute and where we’re going in the future. But before we dive too deeply in to the details I’d like to share what we mean by “Infrastructure Security” and what our guiding principles are.
Infrastructure security can be described as "the discipline dedicated to securing the platform on which applications reside." While there may be a gray line, we try to differentiate by team capability rather than by explicit technical demarcations. Yes, there is some overlap between application and infrastructure security (most notably in host configuration and hardening). However we believe that by encouraging our engineers to look beyond baseline requirements almost always yields better results and as a manager I am willing to invest in the extra cycles of my team.
ACE Services is a consulting team created to help clients ensure that they're doing what they should to keep Microsoft as reasonably secure as possible while still doing business successfully (think technical lawyers). However, it is important to point out that we do not operate as a system of jurisprudence (read: we're not traffic cops). We have embraced the fundamental notion that, as a service organization, we are here to facilitate and advise in the most efficient mode possible while enabling the business to keep moving forward. I am often confronted with the question: "If you are a Service, then aren't you optional?" Where the pairing of "Service=Optional" came from is a mystery to me, as we are all reminded of this on April 15. Security is not an option, but the ultimate responsibility lies on the asset owner to behave in a secure manner and on asset custodians to maintain a secure environment.
Ultimately, the security of information assets is a shared responsibility. While the breadth and impact of the Infrastructure security team is wide we can't be everywhere, all of the time. We rely on the individual business owners, engineers, and administrators to do the right thing. We provide guidance when they need help. This respectful collaboration works well, so much so that we have been taking our work outside the walls of Microsoft and have been delivering them to Microsoft Consulting Services' customers as well.
In the weeks and blogs to follow you will hear about the tactical reviews, strategic assessments and holistic programs the ACE Infrastructure team delivers. We invite you to watch our new podcast - "About Infrastructure Security" where I talk about our role and how our team works inside and outside of Microsoft. There will be more upcoming podcasts as well as promotional literature posted soon. For over a decade Microsoft has been focusing on securing Microsoft’s internal infrastructure; however this is the first year we've taken our proven process, knowledge and insight to our customers. The success has been exhilarating and we look eagerly to the years to come with anticipation. This is what we love to do—and we're good at it.
After experiencing what we've put together don't hesitate to contact us with questions, comments, rants or raves. We look forward to hearing from you.
-Brad Gobble
ACE Team - Infrastructure Security
Hi – This is Irfan, Director of the ACE Team. Some of you may have come across Abu’s recent blogs on Performance Development Lifecycle for IT (PDL-IT), I thought it would be useful to shed some light on the history of the performance side of the ACE Team as well as discuss what led to the creation of PDL-IT. As mentioned in my earlier blog, the ACE Team was originally formed as a dedicated performance team back in 1999 and we’ve been going strong in the area of performance for 10 years. Prior to ACE’s existence, centralized performance testing in Microsoft IT was conducted by the SAT (Software Acceptance Team). SAT was formed in 1996 and it’s primary goal was to review operational specifications of LOBs and test those applications against those specifications to ensure they were ‘ready’ and ‘able’ to be released into production. Part of the testing conducted by SAT was load testing. Testers would review the operations specs where the business would have articulated the anticipated user load and from there tools/scripts would be put to use to simulate that load. SAT remained in existence until 1999 at which time the testing they were conducting was rolled back into the development teams, however the benefits of a dedicated performance team stood out and those individuals who were driving load testing were spun off to create ACE. So that was the Cliff Notes version of ACE’s history with performance testing, now moving onto PDL-IT…..
PDL-IT is a direct result of best practices and standards that we’ve compiled over the past 10 years. Through PDL-IT we’re able to build into the Software Development Lifecycle the necessary performance testing milestones needed to reduce the risk resulting from costly IN PRODUCTION performance issues. As is the case with security issues, if you are able to uncover problems early in the development lifecycle the cost (in terms of man hours and budget) to fix issues is dramatically reduced. That’s why you’ll find that through PDL-IT it calls for the engagement with application teams as earlier as the envisioning stage. That’s when the business owners are sitting across the technologists describing the business objectives they’re trying to hit. Part of that discussion MUST be about expected user loads thus providing context around desired performance goals. The other reason behind PDL-IT was a more simplistic one, that was to put a ‘name’ to our methodology. Its much easier when talking to application teams to say “refer to PDL-IT” Vs “our team’s methodology”. I just finished recording a video that delves a bit deeper into PDL-IT, if you’re interested in learning more about the methodology you can view the video here. Hopefully between Abu’s blog and my video you have a better idea of PDL-IT, we do plan on publishing more information on the methodology but meanwhile we look forward to your comments and questions.
You’ve probably heard of the famous Heisenberg Uncertainty Principle in Quantum physics. It states
“The more precisely the position is determined, the less precisely the momentum is known in this instant, and vice versa.”
--Heisenberg, uncertainty paper, 1927
This principle is related to the observer effect. In physics, the term observer effect refers to changes that the act of observation will make on the phenomenon being observed.
Ok, now to get to the point. Read more…
- Akshay Aggarwal
If you like this post, subscribe to the RSS feed
