The security of Web Applications matters, so you do need to take an interest in the vendors

  • Home
  • /
  • Blog
  • /
  • The security of Web Applications matters, so you do need to take an interest in the vendors
  • Home
  • /
  • Blog
  • /
  • The security of Web Applications matters, so you do need to take an interest in the vendors
March 15, 2021

The security of web applications C2 Cyber
The security of Web applications is increasingly important and if the world wasn’t already going headlong into cloud adoption before the pandemic broke out, the last year has certainly accelerated that.  Sometimes the driver has been to make tools available to staff from home because the old legacy version couldn’t be accessed outside the office perimeter.  Perhaps the largest driver though has been to adoption of tools to enable remote collaboration because face-to-face collaboration has clearly been off the table. 

However, just because a web application has a slick interface, that has been polished to within an inch of its life by a user experience agency, does not mean it is trustworthy.  In reviewing a broad range of vendors, we have seen all shades of “The Good, The Bad and The Ugly”.  We thought we would share some of those findings, and our views on why it matters. 

Why does the security of Web Applications matter? 

These web applications may appear fairly benign.  Nothing to install on your users machines.  No data ending up on your users machines.  Everything managed by the service provider.  What could possibly go wrong?  Well, it is true that there are some benefits in a shift to a multi-vendor portfolio approach in the cloud.  But there are also hazards that didn’t exist before. 

There are material security benefits 

It is true that there are some notable security advantages in moving applications off your devices and environment and into the cloud.  The reduction of software being installed on employee devices both reduces the management overhead and the risk of vulnerabilities and malware being introduced.  Vulnerability management becomes more manageable.   

Getting the data off individual devices and in a secure cloud environment, which is only accessible through the browser, can significantly reduce the attack surface that this data is exposed through.  Also, getting the application off the users’ devices and accessed “at arm’s length” through a browser means that if a user’s device is compromised there is less risk that the attacker will be able to gain access to the application and its underlying data. 

By taking a multi-vendor approach you may also find that you are segmenting different types of data in different locations.  With data, and the applications handling it, residing in totally different environments the risk of contagion from one to another can be reduced.  Now, if your marketing application is compromised it is unlikely to enable the attacker to pivot onto your ERP, HR, finance or email systems. 

But there are also some risks, and they can be hard to measure 

However there remain significant areas of risk.  The data may is no longer stored on user devices, but it now rests on the vendor’s infrastructure.  Its security is entirely dependent on how seriously that vendor takes security.  Where you previously had all of the responsibility for securing your on-premise applications you have now delegated those responsibilities to a third party.  And this target may be more attractive to attack now than your systems were before.  An attacker will find it attractive to attack one large cloud service that will give them access to the data of lots of businesses in one place. 

So the vendor now holds the responsibility.  How do you know that it has appropriate encryption in place to protect data at rest?  Where your own staff could previously be the weakest link this now moves to the vendors employees; do they have appropriate HR controls in place and is their approach to identity and access management strong enough?  Do they have any vulnerability management in place and how robustly do they implement and test network security from the edge to the core.  All of those controls that you previously spent time and effort to put in place and enforce are now out of reach and without action they are also out of sight. 

This situation multiplies somewhat if you are connecting these applications together or to your retained back-end systems.  Now some of the contagion risk returns, albeit reduced because the routes are likely to be limited to some REST-APIs and the payload that travels over them.  But you are now exposed to a situation where a compromise of one system might give the attacker remote access to the data in a number of others. 

You may also need to explicitly define this delegation of responsibility in contract.  For instance, if you are handling personal data from the EU and the vendor exists in the USA or another country without recognized equivalency you may need to enforce Standard Contractual Clauses. 

Then is it all worth it? 

So there are benefits and there are also new risks.  Whether the benefits outweigh the disbenefits is only a decision that a business can make itself, taking into account their own context and their risk appetite.  However, I would suggest that if the risks are well managed then the security benefits definitely win.  Just look at the recent news about the huge number of on-premise Microsoft Exchange systems that have been compromised as a result of a vulnerability.  Closing that vulnerability across all of the business affected will take a long time.  It is difficult to see why a business might feel that they are in a better position to manage a complex system like Exchange than Microsoft can itself; and to be clear, some of the most secure elements of Government came to that conclusion several years ago. 

So what can be done to secure your Web Applications? 

The solution is good risk management.  Managing risk is a great way to grasp and exploit opportunity to win.  The benefits are there, but should only be accessed if the disbenefits are understood and addressed.  Our approach to vendor risk management is all based on “Trust, Verify and Collaborate”: 

  • Trust.   You need to be able to trust vendors to an extent.If you don’t a vendor then why you are even considering handing your valuable and sensitive data to them.  Some of that trust comes from asking the vendors to explain their approach to security in the particular areas that are relevant to the risks.  We have a broad and continuously updated way of collecting and analysing this information to identify risks and vulnerabilities. 
  • Verify.   But the basis of the trust should be verified.  We verify from a number of different perspectives.  Proof of certification or audit can provide some verification, such as ISO27001 or SOC2.  Evidence in the form of effective policies, that have been regularly reviewed and updated provide additional confidence.  But this is all provided by the vendor themselves, and there is no guarantee that policies are being followed.  So we also look to outside for open source intelligence that provides additional verification.  On its own this intelligence won’t tell the whole story, but it can provide a strong proxy for the overall maturity of the organization. 
  • Collaborate.  But when an issue or concern is identified, a risk that is outside your appetite, then something needs to be done.  This is where collaboration is so vital.  The Vendor and Customer’s interests should be fully aligned.  They are both at risk from the vulnerability and by collaborating they can work together to address it.  And if the vendor is not concerned about the vulnerability then the trust definitely needs to be called into question. 
__CONFIG_group_edit__{}__CONFIG_group_edit__
__CONFIG_local_colors__{"colors":{"8b2fd":"Snuff","edb1a":"White Lilac","83d40":"Ship Cove","20090":"Scampi","4f35b":"Rose White","b98f0":"Turquoise","772bd":"Turquoise"},"gradients":{}}__CONFIG_local_colors__