Category Archives:

HIPAA Compliance and Office 365


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2013-08-27-SharePointSecurityImpact-01.pngHealthcare organizations have to share patient information but they also have to keep that information private. The two requirements are in direct conflict.  Add the Cloud and things get really “interesting!”

Cloudy with a chance of breach

Everyone wants to move to the cloud – especially for file sharing use cases. For larger healthcare organizations the motivation to move to the Cloud is often to consolidate enterprise users to a common platform (as opposed to the scattershot “shadow IT” approach that exists today). Smaller companies often just want to get off servers. Regardless of why HIPAA covered entities are moving the Cloud or how big those entities are, the reality is they have patient privacy and security needs beyond what Office 365 and other platforms provide. When it comes to HIPAA covered entities Microsoft’s Office 365 is better than most (more on that later) but organizations need to approach Cloud adoption with a clear understanding of what your hosting provider can do from a security standpoint and what the end-user organization is responsible for. The scary thing is that users are adopting Cloud file sharing platforms far in advance of the enterprise actually being able to manage risk of a breach of patient information associated with those platforms.

Carry a big stick

When the Obama Administration included patient privacy enforcement in the HITECH Act, many of us in the privacy business noted that HIPAA finally got some “teeth.” The HITECH Act and other related changes resulted in very impactful provisions relative to breaches of patient data including

  • The establishment of fines for losing unsecured electronic patient healthcare information
  • The notion of shared risk for companies that provide services (aka Business Associates) to a HIPAA covered entity.
  • The use of data at rest encryption as a form of safe harbor from the breach notification requirements

The Haves and the Have Nots

In the first paragraph I mentioned that Office 365 is better than most offerings. The reason I say this is because of what’s called a Business Associate Agreement (BAA). A HIPAA Business Associate (BA) is any organization that provides services to a HIPAA covered entity that traffic in patient information. A BAA is an agreement that a Business Associate signs to share risk of a breach of patient information relative to the BA’s services. SaaS and other Cloud providers are clearly delineated into two camps: those that will sign BAAs and those that won’t. Microsoft will sign a BAA. Google, Dropbox and many others will not. This dynamic is wreaking havoc with organizations that have patient information. At best they can get existing providers to sign a BAA. At worst, they have to track down rogue usage of services like Dropbox and threaten employees with serious consequences.

Common Threads

In the past several months we’ve talked to a lot of enterprise security leaders in the healthcare space about their patient privacy needs relative to Office 365. They tell us that they do not want to be in the business of controlling who can collaborate with whom but they do need to get a level of central control over patient privacy. These healthcare providers, payers, and other covered entities need to identify patient information in Office 365, encrypt that information at rest (to get Safe Harbor), and track who accesses it. Microsoft’s willingness to sign a BAA just means that Office 365 is on the short list of options. These healthcare systems and other organizations recognize that they, not Microsoft, are responsible for how the enterprise users consume Office 365.

Don’t rock the boat

The reality is there are collaboration platforms built explicitly for regulated or high security use cases. The problems with these platforms are that they are much more expensive than Office 365 and, maybe more important, users don’t want to adopt them. The right way to approach the problem is to make the platforms like Office 365 secure for patient information.

Securing Office 365 so that you can safely store patient information on the platform translates to encrypting the data, applying access controls, and auditing access to the data. With these three technical security controls in place, you’ll be in good shape to prove to auditors that you’re protecting your ePHI as required by HIPAA security requirements.

Data Encryption in a Post-PRISM Cloud


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2013-08-27-SharePointSecurityImpact-01.pngThe recent exposure of PRISM and the role that Cloud providers played in that program changes how businesses need to think about Cloud data encryption. These conclusions reduce to two bullet points:

  1. Implicitly trusting your Cloud provider is not a wise move when it comes to storing your sensitive and confidential data in the Cloud. Enterprises must maintain strict control of their information even while it resides and is consumed in the Cloud.
  2. Highly sophisticated organizations want your data. Enterprises need to adopt Cloud data encryption technologies that follow encryption and key management best practices.

Maintain Control

The Cloud provides great economies of scale for both the consumer of the Cloud service and the provider. For example, Microsoft, Google, and Amazon can buy more and better security technologies because they can split their cost-basis across a huge customer base.

The security challenge, then, relates to maintaining control of your information. As someone in one of my recent presentations said, “once you put your data in the Cloud it becomes the property of your Cloud provider who allows you the right to access it for a monthly fee.” With non-commodity Cloud offerings, enterprises can put the Cloud provider through months of due diligence and contract negotiations. That approach doesn’t work with offerings like Office 365 and the like. The best way to maintain control of your data is to encrypt it before it hits the Cloud and then maintain physical ownership of both the data encryption keys and the encryption/decryption functions.

Leave Encryption to the Professionals

While the US Government is the focus of attention these days (for obvious reasons) don’t forget that there are other nations trying to peek at your Cloud data. Like any other group of competitive organizations, if one is doing it the others are, too. This means that your organization is likely to face determined attackers with plenty of resources.

Here are some top concerns when it comes to the landscape of Cloud data encryption vendors:

  1. Proprietary Encryption Algorithms are the one thing that you never, ever want to use. If an encryption algorithm hasn’t been created, vetted, and accepted on a global academic and government scale then don’t use it. Period.
  2. Usability at the cost of security is an approach that vendors take when they don’t have the expertise and experience to devise a Cloud data encryption system that is both secure and usable. There will, of course, always be an impact to usability for securing your data but remember the first bullet. Cutting corners is as good as doing nothing at all.
  3. Encryption and key management requires a pedigree. Encryption and key management are highly specialized disciplines. Few organizations have the talent and experience necessary to make encryption and key management both secure and usable. There are a lot of moving pieces like Initialization Vectors, sources for random numbers, encryption key storage, key rotation, and key expiration just to name a few. We’ve touched on this topic in previous blog.

Challenges Securing SharePoint Against Privileged Insiders


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2013-08-27-SharePointSecurityImpact-01.pngIt is well documented at this point that some leaked Wikileaks data came from SharePoint sites. Details have emerged regarding how the data relating to the PRISM breach was obtained, and this breach, like Wikileaks, also involved SharePoint.

To provide some structure for this discussion, we’ll break the discussion into three types of collaboration platforms: legacy file servers, on-premises SharePoint sites, and cloud collaboration platforms such as Office 365 and SharePoint Online.

Legacy file servers

Insider security threats in legacy file server environments include classic systems administrator issues (excessive permissions, inability to enforce need to know, lack of separation of duties). Third party products exist that can help add a layer of security control to these environments. These products enforce need to know by using an independent access control and encryption capability, which is usually managed by IT security or by the business manager (data owner).

On-premises SharePoint

Purpose-built collaboration platforms such as SharePoint bring a multitude of security issues, many of which depend on the use case, and the deployment model.

For example, SharePoint when deployed as an intranet collaboration system presents a different set of potential security threats versus SharePoint as an extranet collaboration platform. Regardless, however, it’s hard to argue that the SharePoint platform, out of the box, has sufficient security controls to prevent insiders from accessing sensitive information that they have no valid “need to know” of.

Even if you implement background checks and other process-based controls to mitigate insider threats, consider that administrator credentials are among the most prized targets by external attackers. Given the porous nature of perimeter-only security defenses today, implementing technical security controls that limit the damage that can be done from compromised system administrator accounts is just smart security (and part of a defense in depth strategy). It’s also worth acknowledging that systems administrators frequently take the path of least resistance, by combining service accounts and privileges. This can easily lead to a situation where the sysadmin’s credentials are literally the “keys to the kingdom.”

Locking down premise SharePoint sites requires an additional layer of access control and encryption.

Cloud Collaboration (Office 365, SharePoint Online)

Cloud collaboration systems bring a different set of security issues. Whether SaaS or IaaS, it’s impossible to ignore the fact that in external cloud services, outsiders (in the form of cloud service provider system administrators) are your new insiders (and insider threat).

Here’s an article that describes the havoc that can be brought by a rogue cloud service provider system administrator.

As with premise file servers and SharePoint sites, applying encryption and access control to data stored in cloud collaboration systems is the only way (from a technical control standpoint) to protect access to sensitive data. There are a number of different technical approaches to securing cloud data. Future articles will explore the various ways to do this.

Insider Threats, SharePoint, and the Snowden and Wikileaks Security Breaches


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2013-08-27-SharePointSecurityImpact-01.pngAt a high level, the Snowden and Wikileaks security breaches both highlight the insider threat to sensitive information. The “insider threat” has been well understood (for a very long time) to be very serious (significant impacts are likely from insider security breaches). Also well known is the difficulty in implementing controls that fully mitigate the threat.

Without proper security controls in place, it is fairly easy for insiders to access sensitive information in SharePoint. Note that this problem is not specific to SharePoint. Most IT technologies can be compromised by a malicious individual with administrator privilege.

While both PRISM and Wikileaks involved government entities (a national intelligence agency and the DoD), the threat from insiders and system administrators is a universal one. Every year, we see numerous stories about insiders from a myriad of different companies and industries walking off with sensitive or valuable data.

A few key takeaways regarding the insider threat and SharePoint:

  • SharePoint security should start with understanding the information assets that exist on your SharePoint sites. It’s fundamentally not possible to assess risk without this understanding. I talk with many SharePoint users, and it’s frankly alarming how many have no real idea if there’s sensitive or regulated content stored on the platform, or where it exists. If you’re in this boat, you should scan your SharePoint content periodically looking for sensitive and regulated data.
  • Any organization with sensitive or valuable information in SharePoint is at risk. Certainly this includes defense and intelligence organizations, but it also includes commercial organizations with high-value IP, trade secrets, financial information, M&A information, Human Resources information, and many other categories of valuable information.
  • In any given organization, controls aimed at fully mitigating the insider threat will likely need to include both technical controls, and administrative controls. Most IT platforms do not provide native security controls capable of preventing administrators from accessing information for which they have no “need to know”. This is obviously true for SharePoint deployed with out-of-the box security controls implemented on-premises. It’s also true for cloud collaboration platforms such as SharePoint Online, Office365, Box, and others. In addition, technical controls will need to include a mix of preventive controls (access controls and encryption), and detective controls (audit and reporting).
  • Platforms like SharePoint can be used in high security applications. 3rd party security tools can enable businesses to expand their use of SharePoint, and to bring the benefits of collaboration to new use cases involving sensitive and regulated data (while maintaining security, even against malicious insiders).

Here’s a few external articles involving security breaches where malicious insiders were the source of attack:

The folks at Carnegie Mellon US CERT have done some good work in characterizing insider threats and attacks. They’ve also created an insider threat security architecture that describes the sorts of controls needing in an IT architecture to thwart malicious insiders. See their resources here.

SharePoint Security Impacts From Snowden and Wikileaks Breaches


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2013-08-27-SharePointSecurityImpact-01.pngThe biggest security story that we’ll see this year is the Snowden - NSA - PRISM leak. The biggest security story in the past couple of years prior to PRISM has clearly been Wikileaks. Common threads obviously run through these breaches, starting with the use of SharePoint by both organizations and the attackers in both cases compromising the confidentiality of information therein. The UK newspaper The Register reported a few weeks ago that the Snowden breach involved information obtained out of SharePoint servers. There are so many different angles to these security breaches, and they are so important, that we’ll address them in a series of blog posts over the next few weeks. Topics for these blogs include:

1)   The increasing importance of security controls that aim to keep system administrators honest or from mistakenly putting the organization at risk. While both Snowden and Wikileaks involved national intelligence agencies and the DoD, the threat from insiders and system administrators is a universal one. Every year, we see numerous stories about insiders from a myriad of different companies and industries walking off with sensitive or valuable data or just accidently making information publically accessible. This article describes the insider threat (posted and available here), and will discuss challenges to securing IT systems against insiders that are common to many organizations and IT platform

2)   It is well documented at this point that some leaked Wikileaks data came from SharePoint sites. NSA has also very recently admitted that data relating to the PRISM breach was obtained from SharePoint servers. It is now clear that the Edward Snowden a) was a system administrator, b) had system administrator privileges across a variety of systems, and c) did not have “need to know” for the information that was stolen and subsequently leaked, and d) obtained much of the information that he’s now leaking from a SharePoint server. This article describes specific challenges relating to securing information in collaboration platforms against system administrators, with specific focus on premise SharePoint sites. To many in the SharePoint world,  “SharePoint security” is synonymous with “SharePoint permissions” and the Snowden breach is a great example of how permissions are a single point of failure and do not (in and of themselves) equate to a proper security architecture.

3)   Solving the SharePoint insider threat issue. Protecting data in SharePoint requires the right mix of security controls, and the right architectural approach. Data encryption and access controls at the application layer are critical.

4)   In defense of SharePoint…Both the Snowden and Wikileaks breaches involved SharePoint. This doesn’t mean, however, that SharePoint is inherently flawed from a security standpoint. It does mean that a defense in depth approach needs to be taken with SharePoint, as with any other IT platform. This blog will explore what a rigorous defense in depth security architecture for SharePoint looks like. The key takeaway…SharePoint farms can be adequately secured to store even the most sensitive data, from a multitude of threats, including privileged insiders.

5)   Security of data in cloud services has been a big issue since cloud first emerged. From the perspective of the PRISM program, and the data collected, both enterprises and consumers using or planning to use cloud services have to be seriously concerned about their data in cloud services. You have to approach cloud services at this point by assuming that your data is being looked at by third parties, including cloud systems administrators, and by governmental agencies. This article will look at cloud data privacy and security issues in light of these developments.

6)   If you accept that cloud data is at great risk, you have a number of different ways to approach securing the data. Data encryption is the primary security tool to employ, and there are big and important choices to be made, including where to insert the encryption (on a client, in a proxy, in a SaaS service, or on the cloud computing infrastructure itself), and how and by whom your encryption keys and encryption routines are managed. This article will explore encryption implementation issues related to securing cloud data.

A final thought, and we believe an important one. This is not solely a SharePoint security issue. This is a gross generalization, but most IT platforms, and particularly collaboration-oriented platforms, are challenged to adequately secure against rogue systems administrators and insiders. The solution to securing SharePoint and other IT platforms against insiders will always boil down to careful application of security controls, including ones that are native to the platform, and 3rd party controls that further lock down the platform and data.

An analogy we use: if your house gets broken into, but you like the house, keep the house and buy a security system. People love SharePoint for the collaboration efficiencies the platform brings to the enterprise. Add to SharePoint the right set of administrative and technical security controls, and you’ve got a winning combination. It is possible to use the SharePoint platform for use cases involving highly sensitive data!

SharePoint, Security, and Compliance - Part 9: Security Survey Findings

You may also be interested in: Smartdesk Advanced ECM Apps


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2012-03-09-SPSecurityCompliance-Intro-01.pngThe AIIM organization recently conducted a survey on SharePoint security and compliance, topics near and dear to our hearts. The findings were pretty interesting, and in this article I’ll add some color to the more significant survey results.

First, AIIM asked SharePoint users about the importance of various issues, and over 85% indicated that ensuring privacy/security of content was either essential or quite important. When asked about adherence to compliance regulations, 78% responded either that it was essential or quite important. What’s notable here is that these were the two highest ranked issues, ahead of such issues as ability to collaborate effectively, ability to quickly create new content, ensuring content is correctly meta-tagged, branding, etc..

AIIM also explored how well respondents feel that SharePoint’s capabilities meet their security and compliance needs. Among the largest organizations, 44% called it worrying for them, with another 13% calling it a "disaster waiting to happen". The degree of concern about SharePoint security and compliance drops as the size of organization gets smaller. This dynamic maps to my company’s experience: large organizations are more concerned, and are adopting third party security and compliance solutions first (and fastest). This is likely a result of larger enterprises having more experience with the impact of a security breach.

Looking at the security sensitivity of information in SharePoint, 48% of organizations are storing “Company Confidential” documents in SharePoint, 12% are storing “Secret”, and 4% “Top Secret” documents. Clearly, SharePoint is becoming a repository for information that requires strong security controls.

The survey also asked respondents a number of questions about best practices in use at their organization. An interesting finding here is that only 12% always audit their sites against key compliance and security measures. Writing polices governing use of the SharePoint platform is simple, but verifying that they are being followed is critical. I have lost count of the number of times I’ve heard SharePoint site administrators and architects tell me "I have no idea what’s in our SharePoint sites", or "I’m sure users are storing sensitive or regulated data in SharePoint, but I haven’t looked". Connecting the dots, if 48% of the respondent organizations are storing sensitive information but only 12% are auditing their controls then there is a lot of unmanaged risk out there.

We have made a couple of security tools freely available at the SharePoint Defense in Depth community site, including a content scanner that can help you to easily find sensitive or regulated data in SharePoint, and a SharePoint risk assessment template. Download these free tools, and get a head start on SharePoint security and compliance. We believe strongly in the defense in depth approach to securing SharePoint. As a web-based technology, SharePoint sites don’t exist in isolation, they are network accessible to internal or external user communities, and require a thoughtful approach to securing the information stored on them.


SharePoint, Security, and Compliance - Part 8: Three Critical SharePoint Security Questions to Ask and Answer

You may also be interested in: The SharePoint Shepherd’s Guide for End Users from SharePoint Shepherd


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2012-03-09-SPSecurityCompliance-Intro-01.png CipherPoint’s CTO, Woody Shea, recently did some web research looking for SharePoint sites exposing sensitive and confidential data to the internet. The research provides cause for concern, and the results were alarming enough that I asked him to write up some security tips to help administrators determine how much security exposure a SharePoint site exhibits via the internet, and what to do about it.

Three Monthly Questions to Ask, and Answer, About Your SharePoint Data Security

This is meant to be a quick guide, a starting place, to get you thinking about regularly checking up on the state of your data. A good time to work on these questions may be whenever you’ve annoyed your loved one and you need something to do while hiding out, or if you just need a bit of time alone. No matter what the trigger, about once a month, grab a keyboard, pull up a chair, and see what you can find. The essence of my guidance here is hack yourself, preferably before someone else does!

What type of data do I have in SharePoint, and where is it?

This is a straightforward question, but sometimes a hard one to answer. Because SharePoint is specifically designed for simple collaboration, data can and will easily flow into, and around, the system. It’s one thing to create great security policies for SharePoint, but regular monitoring is essential to ensure that your data security policies are actually being followed.

Once you have located sensitive or restricted data, you need to ensure that it is where you expect it to be. Probably on an internal-only site. In my research, approximately 40% of the data that appeared to be a breach of some sort (often marked something like ‘internal-use only’) was either mis-filed or copied to an external site. The other 60% consisted of the accidental exposure of entire libraries which should not have been open to the public.

While finding and locating sensitive data can be done in a number of ways, including SharePoint’s native search functionality, I recommend a tool like the content scanner found at

This is a free-to-use / ad-free tool specifically designed for the SharePoint community to address this very question. It will find data based on regular expressions, and it produces a report on where the files were found. It has canned searches for various credit card types, US social security numbers, and an easy to use mechanism for building your own plain-text or regular expression searches.

How much of my data is exposed?

This is one of the easiest questions to answer. Google is a great tool for this. The fastest way to get an idea of what you are exposing to the outside world is to simply type ‘site:<your domain>.com’ (without the quotes, and replacing the bracketed text with your own domain) into a Google search. An example might be; ‘’. This will give you a good idea of the pages potentially exposed to the public. From there you can add search terms to narrow in on the interesting data. Maybe add the term “visa”, “master card”, “social security”, or “top secret”; whatever makes sense for your organization.

Please note that I said, “Potentially exposed to the public.” Just because you see the document name in the search results does not mean that the data in the file is exposed. It does, however, mean that one layer of protection (your firewall) has been bypassed. If you find a file you believe has sensitive data please try to open it. If you get a user ID/password prompt, the data may still be protected by the SharePoint ACLs. For each file like this, be sure to try to access the file, but click ‘Cancel’ without entering any login information. In my research for this paper, I found that just under 20% of SharePoint sites exposed to the internet that prompted for a user ID and password would give access to the file after I clicked ‘Cancel’. This segues well into the next question, “Are the exposed sites configured properly?”

Are the exposed sites appropriate, and configured properly?

By default SharePoint is configured to be pretty secure. Unfortunately the ACL controls can be a bit confusing, potentially leading to configurations that are less than optimal from a security point of view. From here, you should have a small list of sites that are exposed to the public, and a good idea of what sort of data exists on said sites. Now would be a good time to correct any inappropriate content, notify the correct authorities (if confidential data was found to be exposed to the public), and pay any necessary fines.

Don’t worry, I’ll wait…

Right, now that the checks are written, let’s look at what is actually exposed to the public. The following is a list of sites that should never be exposed. If you do find these titles coming up in your Google search, you need to take action. Either make sure they are nicely tucked away behind your firewall or, if you find one that is just a regular list or library that should be open to the public, please consider re-naming it to something else. Ok, now, here’s the list of names you should not see on your Google search:
“view all site content” “sign in” and “people and group”

Try the following Google search:
site:<your domain>.com “view all site content” “sign in” and “people and group”

Make sure nothing shows up, or that they are no longer reachable.

Now, run a content scanner and/or the ‘site:<your domain>.com’ Google search one more time, and ensure there is no sensitive data hanging out where you don’t expect it.


Regularly scanning your data for any anomalies in the exposed content is an important part of maintaining the overall health of your SharePoint installation. Mistakes will happen, and files will get moved to libraries where they do not belong. That is simply the nature of collaboration systems like SharePoint.

In many cases I would recommend an additional layer of protection, like transparent file encryption, to help safeguard against such mistakes. In this case, if a file containing sensitive data is accidentally moved or copied to an open site, or if a protected library is exposed to the public, any unauthorized access would only reveal encrypted file(s), not the important data inside.

Woody Shea
CTO, CipherPoint Software

SharePoint, Security, and Compliance - Part 7: The SharePoint Security Mirage

You may also be interested in: Smartdesk Advanced ECM Apps


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2012-03-09-SPSecurityCompliance-Intro-01.png My inspiration for this article came after seeing yet another discussion about SharePoint security devolve into talk about a specific feature of SharePoint. I want to emphasize that security is not a product feature. Security is achieved through the age-old combination of People, Process, and Technology.

As many of you know, a mirage is a false vision of a lush oasis in the desert when the unfortunate reality is there is no oasis - just more barren sand.

The current definition of “SharePoint Security” is a mirage.


As I hinted at above, just about all the SharePoint security topics turn into a discussion of permissions management. Permissions are not security. Relying on permissions for your SharePoint Security strategy is a mirage – more specifically, it’s a single point of failure with massive implications for your organization. I’d be willing to chalk this up as a simple case of vocabulary confusion but, unlike our use of “Xerox” to mean “photo-copy,” in the SharePoint community, permissions are too often meant to mean security.

Permissions are absolutely important and obviously the SharePoint permissions management capability leaves many wanting. The discussions, however, center on how to better administer permissions. There is rarely (or ever) talk of concerns around who should own permissions in the first place? Does the organization have role-based access controls defined at a corporate level? Who in the organization owns the risk associated with the data in SharePoint?


You may be asking, “What about least privilege administration?”

The goal of deploying SharePoint using least-privilege accounts is to remove single points of failure. The reality, however, is that most SharePoint administrators are able to login using any “least privilege” account they’d like, or they have an account that spans least privilege “boundaries.”

So what, or more accurately, who are you protecting yourself against? The idea of least privilege is to limit the damage in the event that any single account gets compromised by an outside attacker. Again, this is a mirage.

SharePoint has a defined set of services and administrative roles with full content access. I’d be willing to guess that somewhere in your SharePoint farm is an account called sa, administrator, site_admin, spadmin, spsearch, etc.  I’d also be willing to bet that the only thing between an attacker and those accounts is a password. Even if the password is complex, you still are relying on a single security control to keep an attacker away from all of your SharePoint content. That assumes that an attacker even needs to crack the password to get the account. There’s a reason that malware and attackers commonly target known, highly privileged accounts.

User Behavior

Another mirage is relying on end users to decide what they will or will not upload into SharePoint. Here are some facts:

  • In their “2011 Digital Universe Study” IDC concluded that 28% of information needs security.
  • In the same study IDC found that that volume of unstructured data (documents, spreadsheets, images – basically what people put in SharePoint) has exploded.
  • Many people have told us they aren’t concerned about SharePoint security since they tell the users not to put sensitive information in SharePoint
  • The reality for most organizations is that they have no idea what information they have in SharePoint

The logical conclusion is that 28% of the content in your SharePoint farm likely needs “security.”  The level of security required to meet the organizational or compliance requirements varies based on a number of factors. User education should be one of the factors but it’s not a substitute for performing the diligence necessary to find out if you have sensitive information in SharePoint and, if the information needs to stay in SharePoint, what are the security requirements.

Extending a site

Another common security mistake I see occurs when extending a SharePoint site to make content accessible from the Internet. SharePoint, among other things, is a collaboration platform and collaborating often means working with teams that are outside your company. Extending a web site may be a best practice for isolating permissions between internal and external users but permissions are not security. Simply extending a web site and opening a port on your border firewall creates a single point of failure between an outside attacker and your content databases.

Get educated

I think the big issue is that SharePoint professionals and information security professionals don’t spend enough time together. If you work in government, financial services, healthcare, or manufacturing then the chances are your organization has a strong information security team as well as enthusiastic use of SharePoint. I encourage you the reach out to your counterparts and try to fuse the two domains. Anyone that uses SharePoint to store employee or customer confidential information, for example, should have a good handle on not just permissions, but also on securing content, a hardened SharePoint environment, and an intelligent approach to making information accessible from the outside. Work with other teams in your organization to see what other controls you need based on your use of SharePoint.

SharePoint, Security, and Compliance - Part 6: Personally Identifiable Information (PII)

You may also be interested in: The SharePoint Shepherd’s Guide for End Users from SharePoint Shepherd


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2012-03-09-SPSecurityCompliance-Intro-01.png In this installment of the SharePoint, Security and Compliance series, we’ll look at the topic of Personally Identifiable Information (PII) and SharePoint. PII is fundamental to security compliance for IT systems. We’ll answer these common questions relating to PII and SharePoint:

What is PII?

What regulations impact the creation, storage, and use of PII?

Do I have PII in my SharePoint sites, and if so, how did it get there, and what do I need to do about it?

What are the impacts to my organization of having PII in SharePoint sites?

Personally identifiable information is information about individuals that uniquely identifies a person, and is generally defined as including these data elements:

It may also include these elements, which, although not specific to a person, may be combined with other personal information to identify an individual.

  • First or last name, if common
  • Country, state, or city of residence
  • Age, especially if non-specific
  • Gender or race
  • Name of the school they attend or workplace
  • Grades, salary, or job position
  • Criminal record

Numerous regulations in various industries regulate the collection and protection of PII. These include Gramm Leach Bliley (US financial services), PCI DSS in credit card/retail, and HIPAA/HITECH (US healthcare). Over forty-five states in the US have enacted some form of data breach law, and internationally, data privacy laws and regulations exist in the EU, Japan, Canada, and elsewhere. Requirements vary, but all of these laws and regulations seek to require security protections for consumer PII, and in many cases they require organizations experiencing security breaches to notify affected individuals and in some cases to make public disclosures. With the cost for security breaches averaging ~$6M in the past few years, it is obviously better (and more cost effective) to protect PII rather than experience a breach, and suffer the direct costs and brand damage associated with recovery.

SharePoint makes it easy for users to share and store information of all sorts. This convenience is a double-edged sword when it comes to sensitive, confidential, or regulated data. Users can easily pull PII out of your organizations systems of record, analyze the data, save it in spreadsheets or documents, and store/share them in SharePoint. How do you know if you have PII in your SharePoint sites? The answer seems simple- you need to look for it! Scan your SharePoint sites regularly looking for PII data patterns. A free SharePoint content scan utility is available here. With it, you can perform scans of files in your SharePoint sites and find PII including credit card data, customer financial information, social security numbers, and other data patterns associated with PII.

Let’s assume you’ve scanned your SharePoint sites, and found files containing PII. What do you need to do about it? The answer depends on what sort of PII, whether it is in SharePoint be design or by accident, and how much control you can apply through policy to your SharePoint user’s behavior. Some organizations that we run across simply write policy telling users to not store PII on SharePoint. The old cold war adage “trust but verify” can (and should in most organizations) be applied to using security policy to try and control user behavior regarding storage of sensitive and regulated content in SharePoint. Even if you’ve written security policy governing the storage of PII in SharePoint, it’s a good idea to occasionally scan your sites and determine whether reality matches your policy.

NIST publishes a guide on dealing with PII that is worth reviewing, Guide to Protecting the Confidentiality of Personally Identifiable Information (SP 800-122).

Among their recommendations are advice on minimizing the use, collection, and retention of PII. In terms of recommended security controls for protecting PII, NIST calls out many of the security controls from SP 800-53, including the following:

  • access enforcement
  • separation of duties
  • least privilege
  • limiting remote access
  • protecting information at rest through the use of encryption

If your SharePoint use case calls for the platform to collect, process, and store PII, then you should carefully design the security controls for your SharePoint site (along the lines suggested by NIST) to securely accommodate this information.

In our next article, we’ll focus on connecting the dots between security and compliance for SharePoint.

Mike Fleck

SharePoint, Security, and Compliance - Part 5: Assessing Risk in SharePoint

You may also be interested in: SharePoint Smart Notifications by KWizCom


Editor’s note: Contributor Mike Fleck is Co-founder of CipherPoint Software, Inc. Follow him @mfleckca

2012-03-09-SPSecurityCompliance-Intro-01.png In our last article, we explored compliance and security risks that may be lurking in SharePoint sites relating to content. The conclusion we arrived at was that it’s hard to know what risks you may be subject to, without knowing what content is being stored in your SharePoint sites.  To help organizations deal with SharePoint content security and compliance, there is a new (and free) content scanner utility that will scan SharePoint content databases, and find compliance regulated content, including credit card numbers and social security numbers. The utility may be downloaded from this website.

Let’s assume you’ve scanned your SharePoint sites, and found either sensitive information being stored in them, or compliance regulated data. What’s next? What should you do to really understand the risks to your business?

I’ll suggest this approach. You should consider doing a SharePoint specific risk assessment. Doing so will give you a better understanding of the actual risks and impacts, and of the security controls presently in place. In addition, doing a basic SharePoint risk assessment will highlight any gaps that you may have in security controls. To get you started, here’s a basic, high-level, 15 question risk assessment for SharePoint. This 15 question SharePoint risk assessment may be downloaded in spreadsheet format here.

Mike Fleck

* Caveats and Usage notes: This simple SharePoint risk assessment should be used to gain a preliminary understanding of risks to SharePoint sites and information. Because SharePoint deployments vary widely in terms of whether they are internal, external, or internet-facing, and what sort of users and content are involved, etc., the assessment should be individually used for each different deployment scenario.

Because this is a high-level risk assessment, and because the relevance of many of the questions and answers will vary considerably depending on the use case, user base, content types, and topology, no attempt has been made to make the results measurable into Low-Medium-High, or a more quantitative risk measurement. Our suggestion is that SharePoint administrators might want to work with your information security or risk management teams to tailor the assessment, and to discuss the meaning of the findings.