As I mentioned in my previous blog post, it seems that delivering real digital government services are being held back for two principal reasons: firstly, the inertia caused by legacy IT systems (the solution to be covered in my next post!), and, secondly, a lack of confidence in their own ability to provide a secure service, be it a concern for data breaches or lack of service (remember the Australian Census problems).
Between these two issues are a plethora of others related to governance, trust, identity, and anonymity. Yet, there are powerful business drivers requiring us to overcome these principles to succeed, including meeting the expectation of “there’s an app for that,” reducing the cost of service, and better understanding and serving its citizens through services.
For government officials, enabling increased access to APIs (the building blocks of digital government) while also strengthening cybersecurity can feel contradictory. And this is a real problem for governments, which are tasked with improving services to the citizens they serve whilst protecting them at the same time. Because if modern APIs are the building blocks for all digital strategies, they are also a prominent attack surface for cybercrime. If Australia is to truly be a world leader in digital government, we must open up more and more APIs to our citizens and partners so that innovative services can be delivered to our citizens, local businesses, and staff (1 in 10 NSW citizens work themselves for NSW Government). But with each new API, how should we mitigate the accompanying vulnerability to cybersecurity threats?
Serving citizens in a secure way
How does a government encourage innovation and ideas, make it easy to do business with, and improve the lives of its citizens whilst also protecting their (our!) data? Can it be done?
Traditional API management approaches are a start. API gateways have been around for quite a while now and are widely used and mature, as far as security capabilities go. Most enable us to easily apply a range of policies to APIs to protect against DDOS attacks, false identities, stealing of payload information, etc. Sure, there will be a need to adopt an overarching governance model to ensure consistent, appropriate security across a government, but that can be done with the right planning and approach.
But (another metaphor alert!), using a traditional API gateway approach is a bit like running a large luxury hotel and only using access keys at the front door. Because just like hotels, many API security threats originate from within. Hotels and government networks both need points of protection close to the valuables. In the case of APIs, this means being able to apply security measures not just at the demilitarized zone (DMZ), but at the system API and process API layers, as hotels only allow guests into the hotel/lift using individual room keys, and, of course, combination locks on in-room safes!
Digital on the inside also means secure on the inside. An API gateway protects organisations from outside threats, but they offer no protection from within your firewall, where a significant threat lurks.
So how do we solve this? What we need is to take that API gateway functionality and apply it to every attack point (i.e. every API) – whether the API is a system API (connecting directly to your systems of record), a process API (combining system APIs and business logic into a service) or an experience API. For an ICT network, this approach solves the “last mile” issue, and for the first time, makes a zero-trust network a possibility.
Application networks: building a zero trust architecture
So how do you build a zero-trust application network? It’s about the management of the set of modern APIs, leveraging a platform built from the ground up around the modern API instead of using multiple vendor products, then managing each API a network fashion.
This is not new to IT— much like the management of networks has evolved, and terms such as Virtual LANs (VLANs), DMZ, firewalls, and introspection are now common terms, we can bring similar concepts to an application network. And we can do this as a separation of duties model and apply policies to API endpoints or sets of APIs and not be required to add or edit code in each endpoint.
Conversations with security, cyber, and risk professionals change significantly when I introduce the above application network concept and talk about how security teams can lay critical security designs without knowing, editing, or managing the code. To tell a CISO they can remove sensitive data from the payload with policy – not code – protect critical endpoints with greater security requirements, and trace data lineage through the application network, they see the potential to work collaboratively with their digital squads or integration teams, changing the conversation from “How do I even quantify this problem?” to “I see a solution.” Pretty powerful!
Being fortunate enough to work with NSW Government and understand deeply their strategy for a digital government is rewarding both as a citizen and someone passionate about this space. I am fully supportive of an open, digitally-enabled government and am confident their approaches to cybersecurity are secure to mitigate the risks described.
To learn first-hand how MuleSoft is accelerating digital transformation in APAC and ANZ, register for MuleSoft CONNECT Sydney!
