Product management, a simple case study.
By: Dimitris Tsirikos
Tags: Interview Questions, Product Management

1 Scope

The goal of this document is to demonstrate initial thoughts about identifying and handling security violation attempts to Atypon customers’ websites that are powered by Literatum. Initial specs state:

“Our clients’ websites are subject to varying degrees of abuse, ranging from password cracking attempts to excessive download attempts and just about everything in between.

What we’d like is a mini-spec for a mechanism for handling abuse in the system: how abuse should be detected, and how it should be mitigated. Include some mock ups for related end-user and administration screens.”

We will focus only on external attacks to the customers’ websites and not cover attacks from internal users (such as a disgruntled employee) or security breaches due to lack of processes (such as the 4-eyes principle, TFA) or negligence.

2 Assumptions / definitions

[Note: these assumptions are just to facilitate analysis of the task at hand. They may not hold true in real life.]

2.1 System architecture

Literatum is a SaaS solution allowing publishers to manage the UI / UX and content of their website, as well as handle users / subscriptions. Literatum also offers advanced search functionality based on arbitrary taxonomies, citations and a plethora of criteria.

Literatum is built on Java (it runs as a Java applet) and is typically offered as a cloud service running on AWS. Transactional data are stored on MS SQL server and documents on SoftNAS that runs on AWS (there is no separate NO SQL database such as MongoDB). Metadata are described in XML and extensive XLST is used for transformations, data input / output.

2.2 Network topology

Assumptions (oversimplified I assume):

The CMS is accessible over the internet on port 80 via HTTP or HTTPS only.

A web application firewall exists before the CMS with a normal firewall before the WAF.

A second normal firewall exists between the CMS and the NFS (SoftNAS) to create a DMZ.

No external user has direct access to SoftNAS and all content is uploaded / downloaded via the CMS.

On the same level exists the MS SQL for transactional data / XML metadata.

3 Stakeholders / roles

For the purpose of this analysis we will define the following types of users.[1]

3.1 Anonymous web users

These are anonymous visitors that access one of the customer websites. They will most probably try to:

Scan the site for forms.

Gain unauthorized access to a subscriber account (impersonation).

Inject scripts (injection).

3.2 Subscribers

These are users paying a subscription to gain access to the scientific content. They will most probably try to gain access to content they have not paid for (unauthorized access). They will not launch a DDOS attack on the site as we have identity data for them (because of the subscription).

3.3 Publishers

They are Atypon customers who rely on the website for revenues. Publishers have two types of users

content creators : who log in the CMS and manage its content.

: who log in the CMS and manage its content. administrators: who set the various parameters for the specific publisher and are alerted in case a security breach is detected.

4 Business requirements

4.1 Types of attacks

We are only concerned with attacks on the CMS. We will not examine direct attacks on the Database or the NFS.

We will try to monitor and mitigate the following types or attacks.

[Note: the following definitions of the various types of attacks are just a subset of their actual definition in real life. We just use these definitions to set the scope.]

4.1.1 DDoS

One of more anonymous web users try to take a site down with repeated calls to get content.

4.1.2 Impersonation

When an anonymous web user tries to guess the username / password combination of a paid subscriber to gain access to their account. Typically done via dictionary or brute force attempts.

4.1.3 Unauthorized access

When a subscriber tries to download content, they have not paid for.

4.1.4 Injection

We are concerned with SQL and XML injection attacks, as well as cross side scripting (XSS). Typically done through form submission (such as the search form) or when parameters are present in the URL (either encoded in HTTP get methods or in the URL path).

4.2 Non-repudiation

We must be in a position to prove that an action was made, who made it and when. This allows us to solve issues, such as when a subscriber denies having done a specific action (such as attempting to download content they have not paid for).

4.3 Monitoring

We will monitor all access to the customer website, as well as access to the CMS login screen, in case the infiltrator tries to login is as publisher.

For each attempt to access a specific resource (a web page, a file, etc.) we will log

date and time

HTTP method (get, post, delete)

resource URI (protocol, server, port, path, parameters)

caller IP

caller agent (OS, device, browser)

referrer

Optionally we can log the userID in case this is a CMS user (subscriber or publisher).

Each call for a resource results in an HTTP response that has:

A specific code (200=success, 404=not found, 5XX=server errors, etc.)

A certain response size in bytes

We will also log these too.

4.4 Blocking / alerting

There will be specific thresholds set by the publisher administrator so that we:

Block a caller IP for X minutes if there are more than Y requests per minute from the same IP (DDoS attack).

Block a caller IP for X minutes if there are more than Y failed requests (HTTP error code 4XX) from the same IP (impersonation).

Block a caller IP for X minutes if they try to login unsuccessfully (impersonation).[2]

Block a caller IP for X days if it has been blocked more than Y times in the last 24 hours.

All blocks can be either temporary or permanent. Every block will be logged together with the reason that lead to it (DDoS, impersonation, etc.).

The publisher administrator can decide for which of these blocks an email will be sent (and define the list of email addresses to receive the alert).

The system will automatically send an alert to the publisher administrator each time we have a DDoS block from more than X different IPs in an interval of Y minutes.

In case suspicious activity is linked with a specific subscriber (regardless of the IP address), we will also alert the publisher admin.

4.5 Auditing / reporting

Based on the data logged we will be able to provide reports about

The usage of each customer website (analytics).

Attempts to breach security in various dimensions [type of attack, time, country (based on IP)].

5 Technical Implementation

5.1 Blocking rules

We will be able to combine the parameters to create blocking rules that cover the above cases and also new ad-hoc rules for cases that may arise in the future.

Rules are managed by the publisher administrator.

Rules table

5.1.1 Rules screen

This is a mockup screen for creating rules.

5.1.2 Trigger conditions

We will initially support the following set of conditions that trigger a rule.

5.2 Various

Passwords will be stored in encrypted form in the database with one way encryption (i.e. it is not possible to decrypt a password).

A strong password policy is to be enforced (minimum password length, make sure it contains special characters, not the same as the last X passwords, expires every Y months, etc.).

Each user session will have a maximum duration in minutes. However, the user can press a visual element (such as a refresh icon) to extend it for another X minutes.

Login screens will be shown only over HTTPS.

5.3 Logging

Logged data will be archived in cold storage after 4 months and permanently deleted after 3 years. Logged data associated with specific subscribers or publisher users will never be deleted (due to possible non-repudiation issues that might arise).

5.4 Injection attacks

The first step to prevent such attacks is by setting rules in the AWS WAF to monitor and prevent injection attempts.

The second step is to harden the web application server (there are many available resources on that).

The third step is to write code with security in mind. This is an extremely broad topic so we will just issue a few guidelines:

Use Java persistence to access the database.

Always validate XML against a DTD.

6 Project management

6.1 Implementation time plan

To be defined together with the development manager (also see the resources available for this).

6.2 Internal testing

Based on company procedures (unit testing, etc.).

It is highly recommended to hire a specialized security team to assist in testing by performing penetration testing and preparing scenarios.

6.3 UAT / rollout to production

Deploy the changes initially to a single publisher, see if there are any issues. Then we rollout to a team of 4 publishers and then to everybody.

7 Next steps / feedback loop after live

We should try to measure the improvement in terms of:

Number of attacks per type per day.

Reduced CPU usage as due to blocking the server has to handle fewer requests.

We should also look extensively at the logs to discover types of attacks we have missed. A review should be scheduled every 6 months.