Product Owner Talks: Basic Security Checklist

Today I’m going to review a bit of an untypical subject for a product owner – cybersecurity. I think that this topic is really important for product and project managers. It is our duty to create useful and safe applications for our users. I haven’t heard/read a lot of articles that are specific for the management level which sheds light on the process of cyber defense and the items we need to know about. However, I’ve seen a lot of articles and news stories about data breaches and security failures that lead to a company’s bankruptcy.

Being a product owner, I want to know how to protect my baby-projects from the dangers and threats of the outside world. In my case, I have one advantage – Igor Tomych, CEO of DashDevs. He is a specialist in cybersecurity and data protection. When we review a project’s architecture, its features, or any provided solutions, he seems to always be able to point out a few vulnerabilities. This information is seeded in the deepest part of my consciousness. Consequently, during the development of an alike feature, I can emphasize the danger zones and mitigate them before we start the development.

For me, the security of the product is important, not only because it is critical to adhere to the requirements set forth in the GDPR, PSD2, ISO/IEC 27001, or HIPPA regulations, but because we work with users’ private data, and I want to keep it safe. The simplest example is that most of the applications at some period of time ask permission to upload the user’s contact list to the database. An average user understandably thinks that the process is safe and the data is kept in a secure location, however this might not always be the case. Another example can be illustrated with fintech applications which have access to their users’ money. We need to always be thinking two steps ahead and protect them from fraudulent activities, scammers, and hackers.

I understand that every application can be hacked. In the case of security, hope is definitely not a strategy. Hence, the goal of this article is to make product owners, as well as product & project managers think about the safety of their products.

The first thing that you need to understand is the term TTP. It stands for Tactics, Techniques, and Procedures, and is an approach to analyzing operations of advanced persistent threats. Basically it is a mainframe that helps protect the system from certain actors and threats, and understands how the threat can penetrate and impact the system. In more simple words:

• Tactics describe the behavior during the attack.
• Techniques describe the technological approach of the attack.
• Procedures cover the sequence of the actions of the actor to execute the attack. If you know TTP, you know the behavioral patterns, and can therefore create protection protocols for your system.

Sometimes when we discuss the protection of the system with a client, I can see that they are not so worried about the security of their product. The main justification is that they are too small, or their product is not a likely target for hackers.

However, it is important to keep in mind that the goals of the attack can be different:

1. Gain access to sensitive/business information.
2. Gain unauthorized access to the application.
3. Break the performance of the system.

You may think that security is a headache only for the CEO and CTO. But the mitigation process influences the customer-facing product too. You need to understand that a good user experience may fly in the face of a secure application. For example, you may want to simplify the login process. That’s fine, but the side effect is that it simplifies the process of hacking the system. Therefore, a balance needs to be achieved.

Basic security checklist for your app

I hope you agree that security is really important for a Product owner. However, I realize that we are not engineers at a Security Operations Center (SOC). For the sake of gaining a better understanding, I have divided the process of application development into 3 parts, and illustrated them with examples via small checklists:

1. The client application (iOS/Android/web applications) - the application that is used by the end-user.
2. The infrastructure - where and how your application is working from the inside.
3. The process of development - how your team develops and maintains the product.

These are the core items that you need to keep in mind. From this point you will need to answer in a binary fashion (Yes/No) if you have/haven’t covered the outlined item.

We will start from the Application level:

1. Do you control the number of open sessions at the same time? From the user’s perspective, they need to have the ability to track the sessions and be able to disconnect from any of them when necessary. A bad actor (hacker, fraud, etc.) can gain access to the application. By using this feature, you’ll help your customer protect themselves from fraudsters. From the other side, there is a more straightforward and simple approach, and that is to allow only one session in the application at the time.
2. Is the lifetime of the access token less than 1h? The token can be renewed automatically. If you have an ‘immortal’ token that lives for a long time, you will get large security hole in your system. This token can be sniffed out by a bad actor and may be used for ages in vicious attacks against your company/product.
3. Do you check that the device is not rooted/jailbroken? Rooted or Jailbroken devices have issues with data consistency. Basically you don’t know what is going to happen with the data that will get on this device. Fintech applications forbid the usage of these applications on such devices altogether. Some of the applications just restrict some functionality.
4. Do you have separation of the roles and possibilities in the system? Basically I’m talking about the ACL - access control list. Each user must have access to the functionality they need in order to work, without any extra bonus functionality. I have seen systems where each user had ‘admin’ privileges. So if a bad actor steals the credentials/token, it can be used to do whatever the bad actor wants - clean databases, change passwords, export all sensitive information, and so on.
5. Do you use SSL certificates (or sign up the requests)? SSL stands for Secure Sockets Layer. This certificate makes your HTTP become HTTPS. Basically it helps to encrypt the data that’s being transmitted in your requests.
6. Do you check that the tokens belong to the user who executes the request? In most applications, the system checks that the token is active, but does not check the owner.
7. Do you clean the data from the local storage after the user logs out? While the application is working on the device it needs to store some data in the keychain/local storage. You need to clean this data after the logout. By the way, you need to check what data is saved locally, and check that the data is hashed/encrypted.
8. Do you control the number of successful/unsuccessful calls from one user? You need to prevent a brute-force attack.

The next step is to cover the Infrastructure level:

1. Do you have user activity logs? You need to know what’s going on in your system. But the logs must not have users’ sensitive information in not secure way. All data must be anonymized and hashed.
2. Do you have a monitoring system? The end-users are really bad notification system for your product issues. It is critical that you know, before your clients do, that your product has issues. If your CPU runs more than 80% or the DB stops responding, your team needs to receive a notification. The reason for a CPU overload can be attributed to a DDos attack (Distributed Denial of Service).
3. Do you have a system to manage secrets (credentials, tokens) correctly? A great tool to use is HashiCorp’s product called Vault. It has open-source and enterprise products, that allow you to store secrets, manage access policies, revoke access, and so on.
4. Do you have a firewall set up? The firewall must be part of your computer system or network which helps you block unauthorized access to your environment. But you need to understand that the Firewall itself is not a silver bullet. You need to have the correct configuration of the rules. Common mistakes are giving more privileges, not restricting connectivity from outside the network, and so on.
5. Do you have a backup system? You just don’t know what can happen. Your system can be hacked, another deploy can break the consistency of the database, or you have an issue with your hosting providers and need to migrate immediately.
6. Do you refuse to obtain hardcoded credentials in your system? It is not secure, it is hard to manage, and is always the source of the issues. Your application can be reversed and a bad actor can gain access to your sensitive/business data.
7. Do your tokens expire for all blocked users and forbid the renewal of the token for such users? This is one such bug that we’ve noticed in a few products. The blocked user couldn’t use the mobile application because it checks the status during the login of the application. However, the token was generated and the bad actor was able use the API calls. Another issue there was that API call didn’t check the status of the user.
8. Do you have end-to-end encryption? This can help protect your data from the man-in-the-middle attacks. Your data is encrypted, and only some users have access to your unencrypted data.
9. Don’t you use SHA1, do you? SHA1 stands for “Secure Hash Algorithm 1”. It is a cryptographic hash function designed by the United States National Security Agency and released in 1995. A few years ago it was compromised. Better to use SHA-256 or SHA-3 on your software.

The last level is the process of development and maintenance:

1. Do you have a passcodes rotation policy? In a great number of companies, one password can work for years. It’s a bit frightening to be frank. Basically, you need to have internal rules that are applied regularly (i.e. once in every 2 months) or in extra important cases (lost device, a fired developer, or a defined security bridge).
2. Do you have a matrix of security risks or TTP? These docs must be implemented from the beginning of the development and be updated constantly.
3. Do you have the documentation of all security and architecture approaches? I know that there is always no time for it. However, your security team needs to know how the application works from the inside.
4. Do your developers have code style guides for the team? If your team consists of more than one developer, you need rules that allow you to control the code quality level.
5. Do you have a Mobile device control policy for the team? Mobile devices are a major source of data leaks, most of the time. The craziest example was when military soldier was using Strava applications while they were in an active war zone. He wanted to stay active and connected with his friends. So, each morning his personal morning run sessions were recorded and made it publicly available. In other words USA secret military operation become less secret. If it happens to the military, it can happen to every business. Your co-workers should be prohibited from using business data on their personal mobile phones. Another way is to forbid the installation of some application or using jailbroken/rooted devices. The main rule is to update the software in the meantime.
6. Do you have the process of escalation and an incident notification process? Your system can go down when you are out of the office (it usually happens so). You need to have a tool that will notify the necessary people via a channel where it is guaranteed that they will receive it, and can react to it.
7. Do you have a responsible person from your side who has been controlled partners relationships? If you think that gaining access to your system is hard, then you might need to think again. Hackers often write emails introducing themselves as a new worker in your company. They ask to create an account, restore passwords, or something in this fashion. That’s why you need to have a person who has privileges to manage access at your partners’ services.
8. Do you use external penetration testing of your application? Here I want to emphasize that developers are not security engineers. They usually know the basics and best practices. However, mitigating security risks is a full-time job which is done by SOC engineers. They can be unaware of some security holes in the code they produce. Another issue is that they are a little bit blind to their own product. They definitely know how it should or shouldn’t work. Consequently, can become hard to think outside the box.

Your results:

How many “Yes” answers for the relevant questions do you have?

If you have positive answers of more than 80%, you are on the right track. You just need a few extra steps to make it right. If you have less than 80%, then you are in danger of being hacked.

The main goal of the above checklist is to make you think about the security of the product that you have and/or are developing. I know that a lot of products nowadays start off as proof of concepts (POC). During this initial stage of development, a lot of entrepreneurs don’t want to mess around with the security aspect of their project. And after the POC gets approved by the investors, they forget or perhaps overlook the technical/security side of their operation. At the end of the day, they are going to pay more simply because their personal data will be exposed to bad actors.

As a parting word, I want to emphasize that the very first step to the security of your product is to educate your team. You need to have regular security awareness trainings to comply with international standards. The more your team knows about TTP and bad actors, the better off you will be. You need to explain:

• why you need to change passwords,
• what are fishing emails,
• why your co-workers need to avoid flash-drives that are lying on the streets, and so on.

You especially need to be careful with non-it specialists (managers, lawyers, sales, accountants). They are the most non-protected target audience for the attackers.

I hope this article can help you review the approach that you are taking to secure your application.

Stay hungry, stay safe.