Udostępnij za pośrednictwem

Infrastructure Security Design Review

  • Artykuł

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

Comments