The article examines the vulnerabilities of growing web applications that are being deployed in e-Governance. It explains how a web firewall is essential to safeguard web applications. And also provides insight into “end to end” security measures to ensure secure and controlled access to e-Governance applications and portals.
As applications grow to enterprise scale, the architecture evolves from a simple ‘stand alone’ or ‘two-tier’ to ‘three-tier’. Earlier user interface programmes were proprietary programmes using non-standard protocols, where very minimal logic/data was exposed to prying eyes. With the advent of Internet, the front-end user interface is increasingly standardised to a browser using HTML. HTML is standards-based and available across any browser and connectivity, increasing the flexibility of connectivity. Yet it openly displays the ‘client source’ to any one who can do a ‘view source’. Layout of different fields, field validations and some amount of business logic is typically embedded in the HTML pages. Sometimes, even database operations are exposed in these HTML pages. And the URLs are another aspect, which allow the browser to call up different parts of the application.
Clear text HTML pages and URLs pose the largest ‘application risk’ to the new generation of e-Governance applications/portals.
Typical ‘network security’ consists of 1) firewalls, 2) anti-virus, 3) encryption and 4) IDS/IPS (Intrusion Detection/Prevention System). Though some parts of ‘web protection’ are built into firewalls (through deep packet inspection), majority of the complexity is still not handled by any of these products.
Also, traditional firewalls cannot look into the web traffic – since they are all encrypted. The data session can be decrypted only by two parties – the ‘web server’ (inside the corporate network) and the communicating ‘web browser’ (on the user’s machine). No other programme, machine or appliance can decrypt that encrypted data in the middle. Hence, traditional firewalls are handicapped in looking into web traffic.
Instead of enforcing “practices of secure coding”, and deployment of only “secure web applications”, companies are resorting to ‘singular defense’ to their web servers – using “web firewalls” or “port 80 firewall”. A web firewall acts as an intermediary, between the user’s web browser and the web server, by ‘decrypting’, –> filtering hacking attempts –> and ‘encrypting’ the traffic.
Althought, is not that difficult for a web server to invoke (SSL) to encrypt, and build in a few web security controls, but such methods are not scalable, beyond a few web applications or a few releases. Web firewalls are the only method, currently available, to ensure ‘uniformly high standard’ of web security, across all backend web servers and different releases and patches.
Web firewalls can encrypt the traffic from user browser, using a standard method such as SSL/AES, and offload such responsibility on each backend web server. Similarly, web security controls are defined in the form of “web filters”, standard out of the box or configured to suit the complexities of a new application.
Problem with too many User Ids (Identity & Access Management)
Every application, typically starts with a ‘user id’ to manage and control. As web applications are easy to develop, by different departments and for different functions – after an year of development, a division may be left with tens to hundreds of web applications. Each application with its own set of user ids.
It is understandable, how difficult id management will be! Issues are –
• Same user may have different ids with different applications (so not easy to connect)
• Difficult to add users into multiple related applications, if they are not centralised
• More importantly, difficult to delete user ids. When not deleted in time, it will leave ‘unauthorised access’ leading to a greater application risk.
• If Single Sign On is used, it is difficult to synchronise passwords across different id stores
This growing situation can be handled in the following phased manner:
1. Start off by recognising the need for a ‘centralised id’ system
2. Define a central id store and implement using nationally accepted keys such as ‘PAN’ (in India) or ‘SSN’ (in US)
3. Start using Single Sign On, to automatically log into existing applications
4. For new applications, start pointing to the central id store, instead of defining a separate set
Define more Controlled User Roles and Permissions
Define user roles and permissions –at application level–and using more granular policy controls based on the following
1. Time of login
2. Device, its identity (shared or personal) and the security level (based on personal firewall, local anti-virus)
3. Network from which the user logs in (public shared network, government shared network, government authorised internal network)
4. Actual role of the user (end user, sophistication, from a government office, or a citizen service center)
5. Allow controlled login, to different sets of applications, rather than a network or sub network
Define End-to-End Security to Access Citizen Applications End to end security to access web applications is considered as follows:
1. Identify the end device where the user is logging in from
2. Identify the security level of the end device
3. Identify the user network (shared, public, private)
4. Encrypt data, by default, from user device to the application server
5. Identify the user (from a centralised ID store)
6. Identify the applications that the user is eligible to access (based on time and other policy matters)
7. Deliver the applications that the user is eligible to access at the time
8. Apply Web Firewall to protect the backend web applications from any type of hacking attempts
9. Apply user session management across all web application access
10. Log the user out and clean up the session from the browser, without leaving any remains of key cookies or data files
11. Provide audit logs on the intermediary web firewall gateway, recording the user login, including the time, device, location and network.