As my grandpa used to say, security in I.T. is like the expiry date on milk: until the fridge stinks, we never check whether the milk has gone off. Indeed, my grandpa did not know much about security in I.T., he just loved coffee with milk. He had cattle ranches and agricultural properties and, despite the differences, it was important to keep them safe.
Development and operation teams become accountable for their application (or their farms); in an agile environment, security is normally downplayed to the degree of a backlog task: “Add security”. Many times its priority equals zero. Until it is too late, sometimes sadly late, and the milk is off.
On another article we tackled the topic of the elements we consider key to ensure a good policy regarding I.T. security. On this article, conversely, we will talk about “how we access” and “how we authenticate”.
“How we access”
When we decide “how we access”, we refer to which is the medium through which we will take control of a service. For instance, if in order to access it, we go through a web page, a remote connection, or a desktop application. In some of those cases, the service management is highly exposed as regards security.
Some examples are:
- In order to access the application manager we just have to add in the url “/admin”. In this case, an attacker may start using different techniques to access an area with high restrictions.
- Ports for remote connections of productive servers are open to any connection. In some cases, including a protection to prevent access to the service administrator or other resource which is considered confidential and important may disrupt the work of the team. Especially if this is disperse geographically speaking. In this opportunity we will have to balance out risk and the importance of the service against the complexity of how to be accessed.
“How we authenticate”
Regarding authentication, the first thing that springs to mind is user and/or password. So I am asked questions about secure passwords, and I always remember that phrase from the famous scene on the film Spaceballs (1987) by the director and actor Mel Brooks.
Although this may seem a joke or a funny anecdote, many companies, because of neglect, use passwords which are easy to guess, or their products default passwords. Therefore we find passwords such as “password”, “12345”, “qwerty” or “admin”. What is more, for many years the code to destroy humanity was “00000000”.
Passwords do not necessarily have to be extremely complex, they can be memorized; but there has to be a culture of avoiding sharing my user and password to other team members. Mainly when users you share with have high permissions which may affect other users, eliminate resources or alter the continuity of the service. In those cases, measures have to be taken such as using Multi Factor Authentication, a.k.a. MFA, perform a restriction by IP or define some other layer of protection. Of course, none of these measures should affect the responsiveness to a user.
In our applications, we will also have users and passwords whose use is for a system to connect to another one. Normally, those users have access to modify information and part of their nature is to prevent a human user from authenticating him/herself with the same credentials. On another article on the blog how we implement them on a development and production environment can be analyzed.
Some concrete tips on authorization and authentication are:
- Your user and password are like a toothbrush, it should not be shared, not even with your best friend.
- Complex passwords do not provide more security, but anyway, using easy and common passwords is a dreadful idea. Some of the most widely used passwords are shown on annual reports such as on Keeper.com.
- When there exists the need to send access to other users, chat and mail are not reliable media. Anyway, keeping them on the mail or on a plain text is not a good idea either, since it is easier to steal them.
- A database or remote access service should not be exposed to the world without any kind of filter.
- When a device is used for a productive environment, it is recommended to use the default credentials. There are web sites that collect these credentials, such as, Default Password.
- As corporate culture, you should prevent the team from using personal accounts for development, this will make it easier to remove credentials if the user leaves the company or changes to another project.
- When a new member has to leave a project, it is important to have an exit process which enables us to recall any access s/he has within the project.
Security is a culture which is set up from the early start of a project. That is why it is important to bear in mind all these recommendations, and to allocate a value higher than zero to the planning in the early stages. The key is to check the fridge, before the stench is way too thick.