by Ben Robb

Modern Web Development – Javascript frameworks as a new vector for vulnerabilities – Part 1

Traditional applications in most organizations consist of:

  • An operating system, web server and database layer that provices core services
  • A product based framework of code (such as SharePoint) which provides a vendor-managed platform which our custom code builds on
  • 3rd party products that give us additional capabilities (e.g. custom web parts in SharePoint applications)
  • Compiled code written in C# for custom server side code
  • Front end HTML, CSS and JS

Most organizations have a well-established process of mitigating the risk of these applications: we have trust in our vendors that they are providing security updates and will respond to threats. We scan our custom code with automated tools to validate that they are not introducing security issues. We have full transparency over what 3rd party components we are using, and in the on-premises model we have complete control over when and how these components are updated.

This model changes substantially in the new world of modern web application development. The architecture now looks like this:

  • A set of REST / ODATA APIs made available by our vendors (e.g. Azure, Office 365)
  • A chained set of JavaScript modules, often hosted by 3rd party CDNs
    • As an example, a simple SharePoint Framework web part involves over 35k files across around 900 open source modules
  • The custom assets for the application (usually TypeScript, LESS, images and HTML)

For the example above, the developer has typed a single command to scaffold a starter application, but everything else is automatically included because it is ultimately used by the SharePoint Framework. In 99% of cases noone – not the developer, the operations team or the architect – would not be able to easily list out those modules, let alone who wrote and maintained the code they are relying on.

The industry has not come up with a good way to mitigate this risk. At the moment, even if we discovered that there was a security problem with a specific JS library, we have no comprehensive way to determine which of our applications are potentially impacted by that. We have no way to record what versions of what tools we are using.

The nightmare scenario:

  • A zero day vulnerability is uncovered in either the browsers that are used by our consumers, or in a vendor product such as Office 365
  • A JS library that we have unknowingly used in one of our applications is modified to include an exploit of this vulnerability
  • This is automatically used via a CDN or downloaded via node.js

What can we do about this?

We need to actively seek to reduce this threat in the following ways:

  1. Provide better, more comprehensive guidance over the use of 3rd party JS frameworks to your developers, and educate your security and risk stakeholders
  2. Understand what tools exist to perform automated security reviews of modern JS based applications
  3. Start recording which applications are using what JavaScript libraries, potentially via a scan of your source control system, or as a part of your deployment strategy.
  4. Ensure your application security team are actively monitoring breaking news about JS module vulnerabilities

In the next post I will explore some of these options in more detail.

by Ben Robb

Managing Enterprise Risk in your Office 365 deployment

In the excitement of rolling out Office 365 within an organization, Enterprise Risk is often the poor relation to Features, but it is much easier to handle if it is built into your program of work from the start. This blog post outlines a few common risk stakeholders that you will need to engage with as early as possible to ensure a smooth rollout. Obviously different organizations will have different terminology for these groups, but all will have leaders / executives who are responsible for these core areas.

How should I build this into an Office 365 delivery team?

Most successful Office 365 programs are run either as Agile projects (where business stakeholders are intimately involved in the deployment) or have a named individual who represents the “voice of the business” for the project team.

In the same way, you should have a named individual who is responsible for ensuring that the risk stakeholders’ voices are heard, and their needs are built into the project from the outset.

This advocate does not need to be a subject matter expert in all areas of risk, but they should be having regular reviews with risk stakeholders to ensure that the risk needs are met.

Who should this person be?

I have worked in teams where an Enterprise Architect is responsible for this, and in other teams where an engagement leader or program manager has taken this role. However, it should be someone who is able to engage with multiple risk leaders within your organization, and this should be their main role in the project.

What risk areas do I need to worry about?

Every organization will have different structures for managing risk, but broadly the following areas of risk need to be covered:

  • Identity and Access Management
  • Legal
    • E-Discovery / Legal Hold
    • Compliance with regulations [e.g. GDPR]
  • Reputational risk / business risks [e.g. HR]
  • Cyber security and data exfiltration prevention
  • Operational support
  • Change governance

You should keep a risk log, detailing all of the risks that have been identified, external frameworks such as SOC2 that demand this risk be mitigated, and how you intend to implement controls to reduce or eliminate the risk.

The controls you implement for each risks may include:

  • Policies / terms of use
  • Training
  • Configuration / technical implementations of mitigations and controls
  • Monitoring / alerting to specific behaviour
  • Processes and sign-off criteria

What next?

Cloud SaaS solutions have a huge advantage to the business in the way that they rapidly update their features and add new capabilities. That does, however, pose a problem for risk management; as these features evolve, the risk position may be materially impacted. This means that you should build some capacity into your ongoing platform investment to keep risk leaders informed of change and to rapidly react to new threats.

by Ben Robb

Introducing Cloud Application Risk Management

After many years of hiatus, I’ve decided to start blogging again to give me somewhere to document some of my thinking around the state of collaboration and risk management in Office 365 and wider cloud platforms. Expect a mix of:

  • Commentary on risks that need to be mitigated as large enterprises embark on their journey to Office 365
  • A repositary of risk topics, with links to more information from canonical sources
  • Regular reviews of the impact of new features to a risk position

Let me know if you want me to cover any topic!