Office 365 Security Series Primer

Collaborative technology has a unique way of exposing security flaws owing to the sheer everyday enterprise user consumption and the potential value of sensitive or propriety business information to an attacker. The security strategy that a SharePoint architect implements has to remain fluid, graceful and expressive in order to compensate for continuous technology changes. SharePoint as a distributed system combines various resources, progressively growing by provisioning on-demand solutions for the enterprise. In order to maintain uninterrupted and secure operations, proper security services must be implemented since SharePoint is subject to the same threats as other software that operates in the open Internet and networking environment. To increase the overall enterprise SharePoint security posture it is necessary that better security properties ranging from strong authentication and to adaptive content governance be implemented.

This threat landscape is also shifting as SharePoint offers entry for different types of devices and technology, such as mobile devices. Every environment that becomes SharePoint supported introduces new security needs, requirements, and difficulties.  Collaborative organizations and technologies indeed face numerous challenges in the field of security.

As can be evidenced with the new features added to the most recent version of SharePoint the collaborative technology industry is leaning to an IT concept known as consumerization. More enterprise users are experiencing technology innovations in areas such as social media before the technology, and even its baseline concepts, are available and supported by an enterprise. As a result, technology requirements within an organization are becoming more driven by employees, rather than strategic infrastructure decisions made by characteristic IT stakeholders.

The most evident example of this is enterprise users are increasingly demanding a collaborative infrastructure where both a personal and work life can be managed from one point. Utilizing social networking technology skills gained outside the organization this is considered excellent from an organization perspective, since it leads to better business information sharing, more effectual decision-making, and enriched business relationships. However, with the good comes some bad. While there are well-defined benefits of some of these innovation integrations, several security risks such as unauthorized, unmonitored, and uncontrolled use can increase the IT and business risks in areas such as confidentiality of intellectual property and business information.

Exploring the explosion of enterprise in interest in collaboration and social shared tools provide an attacker different avenues than previously available to harvest valuable business information due to the enhanced social features. There were several social tools built into the 2010 revision of SharePoint, but they have been increasingly refined in the recent release. Even lacking technical ability, often times finding valuable information can simply be time and patience since it might be casually and carelessly distributed. This type of data varies, however can tamper with company operations and expose or steal sensitive information. Collaboration and social sharing tools open up new avenues for an attacker to steal propriety or confidential business information or disrupt business operations. Social messages surfaced in SharePoint can be inadvertently used in order to spread malware more effectively and additionally through more multiple devices. Sensitive business information can be accidently disclosed between businesses connections since due to the tight restrictions generally placed on internal data being loosened in favor of the openness of the social media world. Controlling the security mechanisms that drive social sharing tooling is also an issue. A majority of these services are provisioned outside of an enterprises control, therefore compensation to govern these has to be adapted within the enterprise.

The concept of consumerization has also pushed the boundaries of normal collaboration to a readily increasing concept known as borderless collaboration. SharePoint is especially common in this arena as the mechanisms to quickly stand up externally facing environments that respects various security integration are relatively well-known. While extending collaboration can procure additional benefits, such as something as simple as increasing communication levels with business partners and customers, it also introduces new challenges. Various security tasks exist, ranging from simple tasks like whom should have access to what within SharePoint to how should user business information be kept confidential.  The most important benefit of a borderless collaboration initiative is to solve the challenges of an increasingly mobile, collaborative and virtual workforce.

SharePoint security threats come in many forms. However it is important to remember that SharePoint is merely an ASP.NET application, and thus subject to all if not most of the same core vulnerabilities that affect its baseline components. All of the layers that make SharePoint a functional software product, such as SQL server and IIS are subject to distinct vulnerabilities. This leads to a fair amount of threats being considered practical against a SharePoint environment, the platform technology volume is so large. As a result, one of the greatest skills that can be mastered is differentiating between what is a practical threat, what is considered to be a threat, and what should actually be ignored. Each SharePoint environment is in general unique, and used for a different purposes. Security strategies to secure this data have to be adaptive as well to properly achieve organizational security goals. When considering SharePoint security it is important to not get fastened to strictly considering the technology security. While there are several layers that build up SharePoint security it is equally important to secure the tools and content that interact and run on the SharePoint platform. For example, there are many avenues for a SharePoint architect to surface information in SharePoint, either through WebParts or perhaps third party enterprise application integration components. However simply surfacing this data creates a potential security vulnerability since the information could be confidential data or describe sensitive business functions. Supporting restrictions that grant the only the level and types of content is as important as technology stack vulnerabilities.

Every standard SharePoint web request begins the same way. A user, or subject, issues a request to access a SharePoint system. Before SharePoint provides access, a challenge is issued requesting the user to provide a public declaration of who they are. While there are multiple avenues a user can leverage to make this public declaration, such as manually keying values in to client based digital certificates, every approach translates to a user’s identity. An identity in the context of SharePoint is simply stating an assertion about the user. SharePoint issues the question “Who are you”, the user is responding with “I am this”.

Establishing the identity of the requesting user is only a small portion of the process. Following, the determination of whether the credentials being presented can be verified, or Authentication (AuthN in shorthand notation) occurs. After responding to the “Who are you” question from SharePoint, SharePoint issues the question “OK, prove it?” in order to verify that the requesting user is valid and not a malicious party forging an attack. AuthN can incorporate multiple authenticators such as passwords or certificate private keys. AuthN allows SharePoint to not directly possess the required secret, however the mechanisms to verify it’s authenticity.

Following authentication, Authorization (AuthZ in shorthand notation), controls the resources that the user is allowed to access. Whereas authentication is the verification of the identity assertion, authorization is the verification of permission. Authorization always precedes authentication.

Anonymous authentication means that a user has already authorized but not authenticated, bypassing the authentication step.

A real world example of an authentication and authorization relationship can be found when considering a bank. A bank customer may visit to withdraw funds from an account. Upon the member issuing the withdrawal request, the teller will ask the member for identification in order to verify the member is whom they say they are, such as a driver’s license. Following approval and verification of the identity, the authentication request funnels to the credit accounts that are valid for the member. Importantly, accounts that are not part of the member accounts are kept separate. If a non-member attempts to access the same account, their credentials will not process pass the authentication process since they are not considered authentic.Authorization differs from authentication because it is the determination of whether the login is allowed. Closely coupled to the concept of authentication, both authorization and authentication must return true to create a connection to a system such as SharePoint.

Consider this same situation from the bank teller’s perception. The teller controls and regulates access to the account, allowing users to access the funds in an account by authorizing them. The question that the bank teller answers is “Is this the owner of the account?” The bank teller does not have any proof that the presented identity, in this case a driver’s license, is valid. It would not be possible, as the bank teller was not responsible for issuing the driver’s license. The bank teller however trusts that licensing department that is responsible for issuing the license. The licensing department is considered a recognized, trustworthy source of information. The bank teller could optionally reject the presented license for a multitude of reasons, however not because of a known, trusted source. For example, an expired expiration date or a pictured that appears to be dated on the license may require the bank teller to inform the customer that the identity needs to be updated. Another institution could optionally provide identity in place of the driver’s license, such as a passport. The important factor is whether a trusted institution has issued the identity. Critically in this example, the bank teller doesn’t have to understand the process that the bank customer went through to get their license or how the bank customer came to prove their identity to get their license. The bank teller simply knows that the institution that issued the license is trusted.

Summarizing what has happened under the in the customer/teller interaction:

  • The bank teller does not verify the identity directly, rather uses a trusted institution and its issued documents metadata.
  • The bank teller doesn’t need the identifying document in a particular format, as long as it is trusted. A passport, driver’s license, and several other formats would be acceptable to the bank teller.
  • The bank teller is indifferent to how the identifying document was procured or the process that the customer went through to get the document.

This process exists in many common circumstances such as going to the liquor store or going to a movie theater, both are similar transactions that require presenting authenticating trusted identification from the customer. This process is extremely efficient, which is the reasoning behind SharePoint following a similar pattern when it comes to identity. In essence, the identity layer is decoupled from the application layer.


Department Of Defense SharePoint Architecture Guide (DSAG) Part 1 – Introduction And DIEA

I always wanted to put together SharePoint defense industry documentation because of 90% of my career being contracted with the Air Force but never found the time. Oddly enough, I did when I went private sector and only did part-time side federal contracts though :-)

The SharePoint 2010 Department of Defense Architecture Guide is an effort to minimize the friction of a SharePoint deployment into a DoD owned entity. While the focal point of the document is targeted to SharePoint 2010, the larger target is building collaborative tooling in the federal defense industry, and thus has broader applicability.

This compiled, preliminary effort focuses on structuring the fundamental standards required when constructing SharePoint environments within the defense industry. There are innate difficulties when putting together such documentation. The ostensibly more static federal computing infrastructure assimilating dynamic platforms such as SharePoint is a invariable struggle for those that wish to stay on the bleeding edge within a federal environment. I believe this is because of two main reasons:

1) Investment Guidance – Presently for a DoD owned entity (i.e. an entity that while potentially being under another entity is autonomous enough that they have the capability to fuel single, enterprise projects) understanding the investment and return has no baseline standardization, even for those more esoteric, abstruse benefits. This complicates the decision making process since interim forecasting becomes impossible, making it complex to hash out requirements and activities.

2) Lack Of Context – The implementation process of a SharePoint solution into a federal environment is commonly not parallel to those within the healthcare industry. Most federal solutions require a pre-existing context in which to assimilate SharePoint into. Furthermore, this context is progressively more complicated because it involves high-level consideration for concepts like implementation rules to more low-level considerations like constraints.

In order to solve these as well as other conundrums, there has to be baseline documentation established that does numerous things. Preferably this should allow a description of federal SharePoint resources, how they can be operated and managed within the context of a DoD entity, allowing contemporary solutions to be implemented while still ensuring the needs of the DoD are met. Ideally, this should cultivate more interoperable SharePoint environments that not only enable collaboration within a unit or with unit and parent entity, but rather within a branch and even between branches. Since information is a strategic asset, in order to make the most conversant tactical decisions it is obligatory to institute these collaborative defense semantics, this should facilitate better data sharing.

To do this, several of the foundation DoD concepts are going to be introduced and integrated within the terms of building collaborative tooling, in turn this should allow the exposure of the common foundation attributes that can extend over various deployments. Not only will this fortify the particular entity that is deploying SharePoint, but should also allow better collaboration to be cultivated between mission partners. This means consuming DoD implementation standards and weaving it with SharePoint solution building guidance taking into account current policies, directives, visions, and strategies (i.e. NetOps Strategic Vision). The most important of these that are going to be taken into consideration is Defense Information Enterprise Architecture (DIEA) 1.0. This type of foundation is one that offers support. At the same time though it is able to radically augment the transporting speed for that information to net centric operations (competitive war fighting advantage through the robust networking of well informed geographically dispersed forces) for the DoD. This allows them to be able to more easily identify barriers that they have to permeate.

With the information available through the Defense Information Enterprise (the DoD information resources, assets, and processes required to achieve an information advantage and share information across the Department of Defense and with mission partners), everything is available for review. This includes fundamental information, resources including assets, and the ability for an array of information to be shared through communications that this entity has with other layers of the department. There are standards in place to assist with the various types of operations on the management level. This allows the mission of all the fundamentals to successfully be sent throughout the department.

There are many different components that make up the overall portfolio for the DoD. When net centricity is initiated there is still the ability to continue being in compliance with the investments made by the IT department, even when considering collaborative tooling such as SharePoint. Everything that is part of the policies and procedures for management and guidance are included here. This gives the full range of action to be carried out through the use of this type of information architecture.
The DoD has such a program so that they are able to continue offering excellence in the area of IT. They have been very commanding in the area of developing standards including the Universal Core (UCore) XML-based data exchange standard and messaging framework. This is facilitated through Net Centric Core Enterprise Services known as NCES.

The DoD IT allows benefits from the use of shared commuting and communications. They have an infrastructure that works with the Global Information Grid (GIG). The GIG is The GIG includes any DoD system, equipment, software, or service that transmits, stores, or processes DoD information, and any other associated services necessary to achieve information superiority. The DoD also has stand alone information that can be embedded and that is self-contained. That type of information won’t be accessible through the enterprise network. One of their focuses is on creating policies and guidelines is it offers an opportunity for common goals to be reached. The ability to make important decisions based on what is going on with the net centric operation is very important. This makes it a valuable investment and also opens up ample supplementary opportunities.

With the DIEA there is unity for the various concepts found in the net centric strategies. This allows for common goals and policies to be part of the overall solution, including the acceleration of collaborative tooling deployment. The vision that the DoD has is to be able to offer a united system that all can benefit from. This will offer them many advantages that they can share with their partner groups and mission partners.

These advantages include offering an environment where sharing can take place. The data information will be visible as well as easily manageable to those that need it. Plus, everything will be austere to understand and only accessed through a trusted environment with apposite security measures in place. The network will be protected with an infrastructure that makes it possible for the operations to offer both dynamic and interoperable levels of communications. A variety of capabilities for commuting will be offered so that all of the tasks can be completed within that infrastructure.

Through the DIEA there is the ability to add more content to any policies that are already in place. The goal is to make sure that adequate guidance is in place within that framework for the DoD to function at a very high level. There are many rules, principles, and constraints that allow them to only take part in the very best of practices. This won’t be limited by the components of the program.

It is all going to abide by the compliance measures that have to be in place with the net centric vision. The collaborative efforts will be successful too due to the way in which information sharing is offered. It is important to understand that the current revision, Defense Information Enterprise Architecture 1.0, won’t be replacing any of the underlying policies that are already in place. The basic framework is going to continue as it already is.

However, the main benefit of this program is that it allows all of the different areas of the department to be tied together. They can follow the same types of framework to get addition guidance but to also stay within the set policies. This is going to offer more power to those that have to make decisions regarding the DoD and the components found within the portfolio.

This program is going to have a solid impact on the way in which decisions are made for the DoD. The rules will be linked to policies and standards that are part of the overall model. DIEA 1.0 allows well informed communications on important issues to be discussed. As a result it will also continue to make a stronger net centric environment for the Department of Defense. There is a vision they have in place for the future which should materialize in the next 3 5 years. With this in mind the Defense Information Enterprise Architecture will be seen as a tool by the Department of Defense. They will use it to help them identify objective that they will proceed to attempt to implement.At the same time there will be many components in place that may align the various programs of the system in regards to the vision for the entire enterprise and the use of net centrics. All of this is going to further continue to push forward the quality and benefits from the net centric environment that has been created.

The primary purpose of the enterprise architecture structure is to make sure everyone has the right information for guidance and to help them make decisions. Taken into the context of SharePoint, this means consistent deployment types and usage. Granted, this is chiefly talking about those that have a responsibility for IT, however, there is no limit to the ways in which this can be a benefit behind the scenes.

Next >> Department Of Defense SharePoint Architecture Guide (DSAG) Part 2 Accountability, EL Scope, And DIEA Customers