10 Initial Steps Towards Designing A Cyber Secure Technology System

Cyber Security Is A Mindset — Not A Necessary Evil

I can no longer count how many times I have encountered a totally lackadaisical attitude by technologists and programmers implementing security in development systems. This attitude often starts at the very top of the technology ladder from the CEO, CTO and down the pipeline. The conventional wisdom often seems to be that security is just implementing a password system. What goes on behind the scenes using just basic security measures, is done so often and taken for granted, most seem to think it must be one of the simplest things to implement. Today we rely on Google or Facebook Authentication, coupled with Twilio in Apps (or some of the other comparable services). Throw in a certificate for “https” and it is all done. Right?

If any boss or programmer thinks in this manner — you are in real trouble. This is just so wrong, the thought process so misguided that it should cause every single alarm to go off in a world that has become obsessed (and rightfully so), with cyber security.

This misconception, if developed by programmers, can be catastrophic to the systems they are working on and certainly their careers. With the advent of ‘back-end”, “front-end” and NoSQL systems which must talk to one another along with an incredible amount of other moving parts, security must become a major concern. By “major” I mean it should by necessity be part of every single system plan and never seen as an afterthought to be built into a system after it is completed or nearing completion. Adopting the mindset of seeing security as a necessary evil to be dealt with in later stages will always, without fail, lead to delays, security loopholes, cyber incursions and eventually system disaster.

It is important to remember, that many systems today deal with health, insurance, banking and personal data. These systems are constantly being tested and upgraded to prevent undesired access and have layers of cyber security. Nevertheless, weak points in the chain often remain, sometimes not even thought about or attended to until some unauthorized entity manages to access the system.

Rather than talk about it though, I am going to list some major factors for planning & creating secure systems. Let me reiterate. These are major factors to be thought about and implemented while building systems. The article outlines many (but certainly not all) of the layers which require security planning. It does not give any specific code or cyber security products to aid you. Auth2 layers, JWT, encryption methods and other wrapping or communication technologies, are not the point of this article. Rather my hope is to train your mind into thinking about security, understand the layers which need to be addressed and then test, update and bolt down systems you are involved in, on a consistent basis.

System Components Which Demand Security Planning:

I. Data-At-Rest

A. Data Repositories
A “data repository” is simply a fancy term for where you are holding your data. In my world this would be NoSQL systems, but applies to MySQL (and its variants) along with NoSQL systems. Simply put, a “data repository” will refer to any data just sitting waiting to be accessed. This gets much more complicated when you deal with Redis, JSON (if it is being used to hold data and not transferring data) and other such data repositories. All information held in these systems should be viewed as “data-at-rest”.

Our first thought should be to securing the actual repository (we are not yet dealing with the data within the repository). Let me give an example here:
MongoDB has become an incredibly popular NoSQL data-store. When setting up a MongoDB installation there is something called a “super-user”. However, you need to implement this user. It is a fairly painless process which takes no longer than a few minutes. Leaving a MongoDB installation open (or any repository), without defining various user access, and a super-user access means you have left your Data Repository open to any 12-year-old hacker. Yet, in my experience, at professional companies, I have often walked into this exact situation. No users are defined, no passwords are created, absolutely nothing is done to secure the actual repository. Even if your system is on AWS, Azure or other competing cloud systems, or even if it is sitting on a server in your office, you absolutely must secure your Data Repository. Be it MongoDB, Cassandra, Hadoop, Redis, MySQL or just a JSON file. Otherwise you are just offering an open invitation for anyone to access your data.

Point 1: Always secure your repository, with at the very least user-password access. Passwords and connection strings should be encrypted, but more on that later.

B. Data Within Repositories
Data-at-rest, also refers to the actual data sitting in your data repositories. This data is usually held for CRUD (“Create, Read, Update, Delete”) actions or analysis. In other words, inside your data repository which should be secured, lies real data. This too is considered “data-at-rest”, though many fail to make the distinction between the actual repository and the actual data, which can lead again to catastrophic results.

Again, a fairly simple example:
Within your SQL or NoSQL storage (or even your Redis or JSON file) you hold information on John Smith. Assume someone manages to break through the data repository layer. Once inside every single piece of information is open and available to them (read: Credit Card Information, or health information etc.). This data-at-rest if left non-encrypted is just sitting there waiting to be stolen.

The question is how to prevent this? I can hear the moans from programmers saying “he is going to tell us to encrypt every single piece of information in the repository”. Well, yes and no. Sometimes there may be a need to encrypt all that information sitting in those collections or data tables, especially what is known as “sensitive” information. Sensitive information is what you define as sensitive and is sometimes a judgment call, sometimes just a matter of common sense. However, you can be sure that any bank, health, password, insurance information should be considered sensitive. Other information may not be considered sensitive and would require no encryption. However, in CRUD routines, on the insert, update and retrieval of information, creating a decent encryption routine for all the information, may be something to consider. Yes, it will slow down the system by milliseconds at times, and you will be forced to create rather interesting ways to run queries, but if you use encryption in a well-planned algorithm the delay will be slight and certainly worth your while. Of course, you will require a way to access your information by way of queries. Yes, this requires an extra routine or function call and system wide planning, but is well worth the peace of mind.

Point 2: Securing the actual data within the repository is a critical aspect of securing systems. Which data you chose to encrypt, how you encrypt it, and what method you will call when you need to decrypt it, is dependent upon your system, its requirements and a judgment call on the nature of how sensitive your data is.

C. Plain Text Data Files
Often overlooked in back-end systems, are various data files which hold data required to access the system.

For instance, in NodeJS global variables are often held in such files. A great many programmers use the excellent NPM library called, “.env” (pronounced “dot env”). Unfortunately, this is a plain text file (or possibly in a certain context a JSON file). Still, it is plain text. Open it up in any editor and you can read the entire file. These global variables are often used to hold access into the systems, including major passwords, connection parameters etc. are all required throughout your system. (It is for this reason some do not use .env in production environments while others find more inventive ways to encrypt the information.)

Global variables for almost all back-end systems can be held within the OS of the server. However, this means if you have multiple servers you will have to set each one of them up within the OS (or image your main server and copy that image to other servers). You may also embed encrypted information in this text or JSON file, say “pw1=encrypted password here” and have your system decode these through a function call to a decryption routine. Whatever route you chose to go, and there are many, never leave such information in a plain text file. (Remember JSON key->values are plain text as well.)

Point 3: Plain text data files can be an Achilles heel in your system. The simple lesson here is to make sure if you use plain text files to hold sensitive data, decide upon some type of encryption method or obfuscate this information where it cannot be simply stolen and used by non-authorized sources.

II. Data-In-Transit
The term “data-in-transit” refers to all data which is being sent over lines towards the servers, data repositories and back again. It also refers to data going from server to server. Any data being sent over WiFi or cables to any other source is considered “data-in-transit”. This concept is simple enough.

A user opens a web browser or cell phone and logs a site to receive or get information, some type of information exchange will take place along CRUD baselines. A request is made for information and an answer (even if it is “not authorized”) is received.

Of course, there are other systems, such as Chat systems, where data in transit is constant. Messages go back and forth. Even if they are not held on a server, or they are deleted after a specific time period, the data must go from point A to point B and it does pass via a server.

The weak link here is when that data is moving between points. If it is not encrypted that data is easily accessible to any “snoopers”. This type of data snooping and grabbing takes place more often than you may be aware. Just look at Telegram and WhatsApp. Telegram started as a completely secure end-to-end system. WhatsApp added end-to-end encryption as well to avoid this type of incursion.

Even if you completely secure data-at-rest by ignoring the need to encrypt the data-in-transit you are leaving a huge security hole in the system. The data, no matter what the route, Browser <-> Server; App <-> Server; Server <-> Server must be secured. (Do not forget that even in Chat systems, the message goes to a server then is forwarded to the recipient.)

Point 4: It is imperative to secure your data-in-transit. This includes all data which has to move from point A to point B. If you do not protect this data, the system is incredibly vulnerable to attack.

III. HTTP, HTTPS & HTTP/2
The “S” Factor — There is an incredible misconception these days about the implementation and use of https, which encrypts information from the Web-server to the Browser. I wish I had a dollar every time I was told that creating an https website, is just a matter of changing from http to https on the server. Indeed, in the traditional previous generation LAMP (Linux, Apache, MySQL, PHP/Python/Perl) setups, it really was just a matter of setting up the Apache server with a valid Certificate and move to https. You can even redirect all http requests automatically to use https. With the advent of Let’s Encrypt as a free and really easy to use alternative this became easier and much cheaper.

However, in this day and age, with sophisticated back-end systems, the back-end code itself for the system must be changed. For instance, in NodeJS, code for accessing http servers (even using just Express) will be different than code accessing https. This applies to all back-ends these days. Starting a code base using http and thinking it is just a matter of adding an “s” is a drastic oversimplification and will be a costly one as well.

If you use http on development servers, with the thought that it would be just a simple addition of a certificate to an Apache server to create the https, you may find yourself in coding hell. (If your system is new, it will certainly not follow the traditional builds anyway. It may not even need an Apache Server, which will cause more planning for the https module.) Suddenly, a few days or even a day before release, when it is discovered that the code base will not handle https all hell breaks loose. I have seen this happen more times than I care to remember.

Point 5: Building a system with https for security should be done at the very beginning of development. Thinking that throwing in a “certificate” and adding an “s”, is certainly not going to cut it. Keep in mind that renewing certificates (especially Let’s Encrypt) if you have multiple servers on a VPC or NAT Gateway or some other system is not going to be an automatic process. All this must be planned before sending a system into production.

IV. Login & Passwords
There is certainly enough information available on the Web about Login & Password security. Unfortunately, many web developers think using a simple encryption routine is enough for Passwords and login information. As I stated at the beginning, this is not an article about encryption methods. However, there are a couple of salient points you do need to be aware of at the very outset, if only because they should apply to any login procedure. These points effect both the data-at-rest and data-in-transit procedures you follow.

Obviously, after what we have explained above storing passwords without encryption or sending them over lines without encryption is simply a security hole that should not exist. However, even encrypted passwords are not really the answer. There are millions of password decryption systems out there (known as “Rainbow Tables”) for anyone to use. Besides as we all know, passwords are sometimes really simple to guess or find.

Additionally, there is In-House security to be wary of (discussed below).
I will, for the sake of space in this article, not get into all the possibilities and security holes here. What is important, even critical, to remember the term “salt” when it comes to passwords. If you do not know what “salting” is I would strongly suggest at the very least looking at the Wikipedia article: Salt (cryptography)

I will just quote from the Wikipedia article introduction so you understand the basics of “salting”.

In cryptography, a salt is random data that is used as an additional input to a one-way function that “hashes” data, a password or passphrase. Salts are closely related to the concept of nonce. The primary function of salts is to defend against dictionary attacks or against its hashed equivalent, a pre-computed rainbow table attack.

Salts are used to safeguard passwords in storage. Historically a password was stored in plaintext on a system, but over time additional safeguards developed to protect a user’s password against being read from the system. A salt is one of those methods.

A new salt is randomly generated for each password. In a typical setting, the salt and the password (or its version after Key stretching) are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. Hashing allows for later authentication without keeping and therefore risking the plaintext password in the event that the authentication data store is compromised.

Since salts do not have to be memorized by humans they can make the size of the rainbow table required for a successful attack prohibitively large without placing a burden on the users. Since salts are different in each case, they also protect commonly used passwords, or those who use the same password on several sites, by making all salted hash instances for the same password different from each other.
See Wikipedia: Salt (cryptography)

Point 6: Always using “salting” for passwords. Do not ever store non-encrypted passwords in a data repository even if the repository itself has been secured. Passwords and other sensitive material need to contain a one-way hash which cannot be broken with the use of “rainbow tables”. You will, of course, require a system for an authorized user to change passwords or create a new password if they have forgotten their previous one, as the “salt” method is one-way and cannot be decrypted without the original key used to salt the information (which no one, not even you, should know or have).

V. Web & Mobile
It should be obvious that Web & Mobile access is also part of the security process. With JWT (JSON Web Tokens) and/or AUTH layers, (PHP — Laravel programmers will be familiar with the Auth2 protocols) some think that is all which is needed. Certainly, it is a big step, but as you can see for all that has been explained, not enough. Using Google or Facebook authentication protocols (or some of the other authentication protocols out there) is something to consider. Yet some people do not want to use these login possibilities. They want to use the Username-Password combination which they are used to. If you do offer this possibility, then try and follow the suggestions above and below. Of course, with mobile and 2-step authentication, via the cell phone, or using services like Twilio this becomes a fairly simple process, but one which needs to be planned for in your code base.

Point 7: Whatever method you chose to use for access to your Website or App, you do need to plan for it in your code base as well as cost of using the service. You must make sure that everything typed in to log on is secure throughout the whole process.

VI. Redis, JSON and All the Rest

I am a big fan of Redis. Mostly it is used as a key->value data store, though you can get more sophisticated in storing information. Many systems use Redis due to the speed of electronic memory and how fairly simple it is to use Redis to store information. Fortunately, Redis offers encryption in its repositories for the data-at-rest and certainly for the repository itself. (Here I would strongly suggest serious consideration of using “Redis Labs” if you plan to use Redis.)

JSON is most often used to transfer information between browser or app and back-end. However, JSON is also used to hold static information. NodeJS programmers will be used to this concept, especially if they have dealt with PM2 or other such utilities. JSON also allows NodeJS to pick up static information as swiftly as possible.

All static information is considered data-at-rest and should be seen as a possible security breech. The moment you decide on a system or add another factor such as Redis, is the moment you need to start thinking about protecting any information held inside the data-at-rest repository.

Point 8: All types of data repositories must be considered when you chose to incorporate them into your systems. Do not only consider your NoSQL or SQL data store as data repositories. If you leave this data not encrypted and out in the open, you are leaving a huge security breech in your system.

VII. In-House Security

One of the most overlooked and certainly sensitive areas are what is known as “in-house” breeches to security. You can call this “corporate espionage” if you care to be dramatic or “stealing” for personal gain. Whatever the reason is, in-house security really must be a matter for concern. Obviously, your head DBA will have access to the super-admin passwords. There are also some other people in your team who will by nature have access to all this information for reasons of development. Large companies of course have very strict routines and rules about the sharing and sending of sensitive information. However, in our world of startups and CEO’s, CTO’s, COO’s & VP’s who are not experienced, and sometimes have no idea of the what, why, how of development, sharing these critical bits of information is done without any guidelines or over-watch.

Point 9: Communication in a company is always critical and when communication is not supervised such as in Startups, it is done over various systems such as Email, WhatsApp, SMS, Slack etc. Resist at all costs sending sensitive information such as passwords and credentials over any email systems. Keep the “need to know” at a minimum. Does your COO really need to know the access codes to the servers? Do your front-end programmers need to know them? Keep a detailed list of who has what access.

As an extra precaution, build the file with the passwords and connection strings as soon as possible then decide on how you will encrypt it. Anyone requiring access would be added by one validated person into this file, and therefore the user would only know their own personal password and login routine. Also, it really is imperative to keep detailed logs in some sort of data repository on who is accessing your servers from in house. Believe me, sooner or later you will need to review them.

Conclusion:

Staying sane — You will never be 100% secure. Accept this. Make this your mantra. There will always be some hacker out there, no matter how much you try, who will try to get into your systems and steal the data. DDOS attacks will always be out there. Your job is to make sure you sleep at night without worrying about security holes and breeches all the time. Be careful. Understand what you are building and all the moving parts of your system, plan ahead and never leave security to the last moment. It is a mindset.

Point 10: Stay sane. Stay calm. Plan for everything you can think of, understand your system and all the moving parts. Constantly look for that one small thing which you forgot. Remember, stay sane & make security a mindset!

________________________________________

About the Author: Ted Gross served as a CTO for many years with an expertise in database technology, Node.js, PHP and OOP. He has also published many articles on technological topics especially on Big Data & Chaos Theory (in professional journals and online @ Medium & LinkedIn). He is also an author of literary fiction, children’s books and various non-fiction articles. His short story collection, “Ancient Tales, Modern Legends” has received excellent reviews.

Ted can be reached via email: tedwgross@gmail.com; Twitter (@tedwgross); LinkedIn; Medium

Note from Towards Data Science’s editors: While we allow independent authors to publish articles in accordance with our rules and guidelines, we do not endorse each author’s contribution. You should not rely on an author’s works without seeking professional advice. See our Reader Terms for details.