Production software vs. theory
Building production software has its challenges. It is never the same when analyzing a theoretical model versus having a fixed budget, multiple client users and a tight deadline for launching. Moreover, deploying a production platform for east vision systems can mean 100, 000 hits per second. On average, not just on peaks.
We will try to go through some of these challenges with a closer look over DSP/ RTB and programmatic buying platforms in a series of articles.
Everybody is a DSP/RTB platform
As is the case of each new technological step forward, which gets investors attention, the world of programmatic buying is no different. Ian Thomas cleverly notices, “Advertisers, almost everyone – agencies, networks, exchanges – is these days calling themselves a DSP “. But how many of them actually have the technology to support these claims? One of the essential parts of such systems is the platform. That is, the TECHNOLOGY platform, as Ian Thomas further explains in the same article. From our experience of 4+ years in the field of building programmatic buying platforms, we know of only several of them who actually built a software platform. One that can be easily extended to incorporate external modules, as customer needs evolve.
So, what is a technology platform anyway? And what needs to be taken into account when launching a web platform? Be it a programmatic buying platform, RTB, DSP, event planning platform, video platform, social media platform, etc.
General mandatory platform modules
By default, it is generally accepted that platform means software as a service that can be used on a broad scale, by a large number of people, to achieve similar final goals, based on their permissions. This is, anyway, the presumption on which we will detail a set of practices and rules that probably all IT service providers are aware of to some degree. However, few of them actually have the organizational infrastructure to apply to production.
There are several modules that each platform, regardless of its end goals, needs:
- Secure login (with email confirmation, forgot password option, optional Facebook login, etc.)
- User roles (super-admin, admin, account manager, user, etc.)
- User permissions (the super admin would need to oversee all created accounts, be able to create, delete users, etc.)
- UI/UX for easy configuration of the platform options
- API-based back-end for easy maintenance and modular extension
- Reporting system (although this can be so complex that it becomes a platform itself)
- Secured production server code repository (this is mandatory for each and every IT projects)
- Secured production database
- Well-structured, scalable server architecture (to support 900 mil/hits a day, for instance)
- Several different caching layers
- Secured, backup servers
Depending on the platform requirements, various features can then be coded. Features such as payment systems or media profile creation. But the above options are a standard must structure for each platform implementation. On top of them, customization from case to case can be added.
Common security breaches examples
Some of the best practices used to develop these modules seem like common sense, but it’s surprising how many people do not understand the value of quality, responsible coding. We will get into one very spiny problem that will speak for itself about the value of having a development team which follows company standards and procedures. Namely security. Each business that bumps into this word immediately freaks out, and with good reasons. Since we do not have the time to go into all details about the multiple ways a system can be attacked and compromised, we will use only two simple, relevant examples. Both refer to systems using MySQL databases. Not that Mongo, Redis, or any other database option doesn’t have cracks that can be slipped in. But MySQL is our choice for the following two simple showcases.
Remove database history installation
During the database installation procedures, there is a lot of sensitive information that can assist an intruder to assault it at any later time. This information is stored in the server’s history and can be very helpful if something goes wrong during the installation. By analyzing the history files, administrators can figure out what has gone wrong and probably fix things up. However, these files are not needed after installation is complete. It is recommended to remove the content of the MySQL history file (~/.mysql_history), where all executed SQL commands are stored (especially passwords, which are stored as plain text):
cat /dev/null > ~/.mysql_history
Restrict the error log
Ensure only “root” and “mysql” have access to the logfile “hostname.err”. The file is stored in the mysql data directory. This file contains very sensitive information such as passwords, addresses, table names, stored procedure names and code parts. It can be used for information gathering, and in some cases, can provide the attacker with the information needed to exploit the database, the machine on which the database is installed, or the data inside it.
Protect your data and business
It’s as simple as that. Again, these are only 2 examples. But this list of best practices contains almost 22 chapters of similar sets of rules for MySQL only. Now multiply that by the number and types of other existing databases. You just got a fair view of the potential error possibilities. We sincerely hope the readers of this article are not in any of the situations described above. However, there are enough cases when you ask a developer to build for you a simple user management module or to migrate your project on a production server. Simple tasks. More often than not, they will not have any idea of these two mentioned practices. Or develop strategies against such attacks.
When you consider the protection of your entire business, maybe a company with highly specialized internal departments (e.g.: solution architects, server admins, security experts, etc.), solid training and hiring processes is something you want to take into account.