Customizations within SharePoint often require the use of external API’s or references. In discussions with IT and Security, a firewall is often the mechanism used to control and protect externally accessible components such as these. Purely based on an organization having a firewall at the edge, seems to be enough protection.
What does firewall protection do?
Firstly, let’s look at what the firewalls are doing. In most instances, the firewall itself is there to protect incoming traffic versus outgoing traffic. Rarely, do organizations have rules within the firewall that control the flow of traffic that leaves the organization. At a minimum, the only traffic controlled is port based. Most firewalls allow port 80 (HTTP) and 443 (HTTPS) to leave the organization freely. Instead of a firewall, organizations often utilize Proxy Servers to inspect and control traffic.
What does Proxy Server protection do?
Organisations often use Proxy Servers to protect outgoing traffic instead of the firewall, as the firewall is normally controlling network-level access, whereas the Proxy will control end user requests, and control the sites that end users can navigate too. Proxy Servers, inspect the content that is accessed, then based on inspection and classification rules determine if that content can be accessed.
Are firewalls and Proxy Servers enough protection?
On their own, they are not sufficient. The firewall is not normally controlling and inspecting the content, but checking the ports used are valid. The Proxy Server is inspecting content, but normally just against the categories, then allowing or denying. The most any of these platforms can do is to block at the domain and port level.
Think of client-side customization that utilizes a Content Delivery Network (CDN) to bring in a version of jQuery. The firewall would not block it; the Proxy Server would inspect it against its list of categories and blocked domains and allow it through. If that version of jQuery then has a security vulnerability, neither the firewall or Proxy Server would detect that.
In fact, most firewalls and Proxy Servers would only block the domain and port level and allow other files such as Cascading Style Sheets (CSS) and JavaScript (JS) files as part of caching to increase the performance of the site load. The end user may not be able to browse the full site, but a direct link to a script could work.
http://www.maliciousdomain.com – Blocked
http://www.maliciousdomain.com/assets/malicious.js – Allowed
Often this is not the case, the full domain, and all sub-paths get restricted. However, if the external file referenced comes from a trusted Content Delivery Network (CDN) or Publically trusted source such as GitHub them, it would be allowed anyway.
What about NextGen firewall?
If you utilize a “NextGen” firewall platform that does a Deep Packet Inspection (DPI), you might be able to detect security issues like this. The latest versions of firewall technology often include visibility beyond the application or customization itself. This capability ensures the various pieces of each packet are thoroughly examined to identify malformed packets, errors, known attacks, and any other anomalies. Deep Packet Inspection (DPI) can rapidly identify and then block Trojans, viruses, spam, intrusion attempts and any other violations of normal protocol communications.
What can I do to protect my customizations?
Firewall(s) and Proxy Servers(s) are only one part of the protections needed for SharePoint Customizations. To truly protect the customization, a different process is required that controls how these get deployed into the SharePoint On-premises or SharePoint online platforms.
- All code needs reviewing (line-by-line)
- External references need to be validated and reviewed (line-by-line)
- External references need checking against known vulnerabilities
- Modify code that references external files, to utilize integrity hash validation
- Ensure that external references are from known and trusted sources
- Validate any other external calls such as RESTful API or external services
All of these steps are manual and require extra time and management. Truly protecting customizations in any platform can be complicated and time consuming no matter of the size of organization or team.
No, a firewall is not enough. Here is why
Firstly, a firewall on its own is only as good as the rules applied to it, and the features that are part of it. firewalls can rarely distinguish malicious traffic from normal end-user requests. Most malicious traffic is indistinguishable to normal user traffic which means that IT and Security administrators, would not raise any flags if they inspected the firewall logs. firewalls, also do not have the capability of inspecting the actual code that is executing, meaning that unless it gets checked before deployment, it will not stop any of the code from running.
Second, by the time the code executes and reaches the firewall, it may have already performed malicious actions internal to the SharePoint platform, that would not have even reached the firewall. Most organizations do not force every user request to SharePoint through a firewall. In the case of Office 365 and SharePoint Online, the code will execute before an internal firewall controls or blocks the anything. Utilizing cloud services such as SharePoint online makes it much more complicated to use a firewall. You would not be able to block all Microsoft URLs ending in “sharepoint.com.” as that would break access and functionality to SharePoint online itself.
The best approach is to define the processes needed to validate and centrally deploy all customizations. Utilizing a platform that can be used to inspect the code before deployment, then to proactively monitor that same code within SharePoint is the only approach that will work. firewalls, Proxy Servers, and Content Inspection platforms all have a place but not on their own, only as part of a defined analysis, validation, deployment, and management process.
How can Rencore solutions help?
Rencore solutions remove the time and management barrier for inspection of customizations. External references get flagged through the use of code analysis and scanning. These references are then validated and checked for vulnerabilities. The core code used in the customization is also checked and validated for any specific errors or bad practices found within the code.
For ad-hoc customizations within SharePoint online that have not been through a formal analysis and scanning process Rencore solutions still help by actively scanning SharePoint online for customizations, analyzing them, then monitoring them, providing better protection and management.
What is the next step?
If you want to keep your Office 365 tenant governed at all times, check out AnalysisCloud here at Rencore. AnalysisCloud’s 24-hour patrol of the cloud space and the monitoring of evolving governance policies helps keep your environment healthy and secure and your data and information where it is supposed to be – in your hands. Try for fee today!
