An overview of how Application Security (AppSec) can help balance the needs of product usability and security with Product Development.
By: James Chiappetta
Disclaimer: The opinions stated here are my own, not necessarily those of my employer.
Today, it’s commonplace to have those in Product Development (Product Dev) working with Application Security (AppSec). The impetus for this working relationship is either by discovery of an unrealized risk with an existing product or the need of launching something new in a hurry. Either way, AppSec can play a key role in helping Product Dev find a successful balance between product usability and security requirements.
First things first
Product Development is a key stakeholder of any AppSec team. They are on the frontlines translating feedback from customers into designs, features, and workflows that aim to delight. This feedback loop is integral to the overall Product Development Lifecycle (PDLC). Once a feature has been identified, development the Product Dev team will need to figure out how it can be built, with how much effort, and over what duration of time. The goal is to ensure the customer gets exactly what they need out of the product with as little hassle as possible. The unfortunate nature of usability is that it often forgoes security or privacy. At times, this happens without anyone even realizing it. Therefore, an inverse relationship commonly exists between usability and security.
So how can an AppSec team enable business objectives by balancing the needs of Product Development with the needs of security? In order to better understand this dichotomy this post will cover:
- Identifying and understanding product security risks.
- Creating a structured format to deal with product risk decisions as a team, without sacrifice to accountability.
- Understanding the difference between Product Security and Application Security.
Product Security Risk
Product Security Risk — A trade off between ease of use (high usability) and rigorous security controls (high security).
To illustrate, think about your mobile banking application. Let’s say you want to check your account balances and assume you already have an established online account with a username, password, and the mobile app installed.
Currently, in order to perform the task of checking your balances, you need to open the mobile app, login with your username and password, enter a one time passcode (OTP) sent to your email, and then select the account from your dashboard. This takes upwards of 2 minutes to complete, but is a highly secure process.
The Product Dev team at the bank knows this is a high friction flow and wants to create a simpler one. They would like to build a feature where the user can click a “trust this device with access PIN” and use a security PIN to access the app on their mobile device.
The Product Dev team engages both the Software Dev team and AppSec team to discuss the implications. All teams are aligned on the why and the what, but need to sort through the how. The AppSec team astutely identifies the risk of using a PIN. According to research a 4 and even 6 digit PIN can be guessed and/or brute forced easily, leaving a lost or stolen device susceptible to an attack that would lead to a full account compromise. It will be on all parties, collectively, to deal with this risk and they will need to take many facets into consideration.
Product Security Risk Template
Create a product security risk template — Create a Product Security Risk template designed to gather the necessary information to perform the risk assessment and get alignment on a path forward. Put this template somewhere central for the Product and Software Dev teams to reference easily. Creating a consistent format that can be used by others to fill in will help scale the practice beyond the AppSec team. This should create a good level of transparency in both the process and its outcomes.
Let’s see how this might work for the local access PIN feature example.
Note: There are a few underlying security risks (e.g. local credential and session storage) but I will purely focus on the PIN here.
The template —
Current state: Existing mobile app users need to perform a full credential authentication attempt with a second factor (OTP) in order to check their account balances and access all features of the app.
Desired state: Users can opt into mobile device trust with the creation of a security PIN to access the mobile app to check their account balances.
Security Risk(s): In the event of a stolen/lost device, the PINs can be guessed or brute forced, leading to full account compromise.
Likelihood: Possible — Requires a user to lose their physical device and an attacker to guess or perform a brute force attack on their PIN. Approximately 70 million devices are lost a year and in the US, 12% of the owners suffer from fraud.
Severity: Undesirable— This is on a user by user basis and a compromise would create a negative experience for the customer. This could also result in a loss of trust on a bigger scale if the lack of proper access controls becomes publicized.
Significance: High— The brand trust of the company could suffer even without a user’s device being compromised if the feature goes live without adequate security measures in place. There is a large number of tech bloggers and security researchers who could discover and write about it.
- Create a temporary 10 minute lockout after 12 bad attempts against the PIN. Alert the user of abuse via email or text message to a backup phone number.
- Force the user to enter their password when performing any non-read operation, such as creating a bank transfer or changing account details (e.g., associated email or password).
- Create a user device and access dashboard that shows any “trusted devices” and allow the user to remove them and invalidate active sessions.
Risk Matrix Key:
- If you are new to risk assessment then I would recommend looking at popular frameworks such as NIST of FAIR. These may be heavy handed for an initial process but will provide a detailed overview on how to properly work with IT Security Risk more broadly.
- There is an inherent subjectivity in risk assessment and the risk assessor, in this case AppSec, may be biased to rate things more severely to ensure issues will get fixed. The AppSec team should use a peer review process and also go into the discussion with Product Dev with an open mind.
Together is Better
Conduct a team-oriented decision meeting — Once your AppSec team has completed the risk template, it’s time to sit down with the Product and Software Dev teams to discuss the risks and what to do about them, together.
It’s likely that you will need to live with some risk at first in favor of speed of delivery. For instance, in the example above, you and the team may walk away with having option #1 being adequate for initial feature delivery but with a plan to deliver the other two controls over some agreed upon period of time. Additionally you are going to need to account for the work with a product development plan. Use a ticketing system to help keep track of the planned work.
If you can all work together to increase security without sacrificing usability, or even increase both usability and security, then those are huge wins. That may not always be possible, but if you go into a product risk discussion with that objective, then everyone will walk away a hero.
Risk Acceptance — Punting on product security risks is a slippery slope. Often when Product Dev is willing to make a tradeoff, the follow up may end up deprioritized, even if it’s written down in a project plan or ticket. Whether it’s all, or just some of the security controls that end up on the backlog as unmitigated product security risks, you will need a strong process to deal with this. Without diving too deep on risk acceptance (we will return to this topic in a future post), at a high level, you will want the following:
- A risk register to keep track of what products have what risks and when they were added.
- A risk acceptance form.
- Established cadences for risk remediation or re-acceptance grouped by risk severity (e.g. Highs every 90 days).
- In the event of acceptance, have a senior business leader (VP or above) provide formal risk acceptance in written format. They will own this risk for the business.
Pro Tip: Perfect can be the enemy of good in this case. Getting the most secure solution into the customer’s hands can’t come at the cost of delivering no solution at all. I am not suggesting that we should release products with major flaws, but finding the right tolerance to risk is fundamental in a balanced approach.
Once there is alignment on the path forward, the AppSec team can support the development of that feature using the portfolio of services it already provides the organization. This includes secure design review of the technical solution proposal, secure code review, and penetration testing (pentesting). You may want to see my other posts for more details on these services:
- (1) Security Design Reviews & Threat Modeling
- (2) Central Security Services for addressing common security problems. Build and Release system security scanning.
- (3) Application Security Penetration Testing
Product Security vs Application Security
I have spoken about Product Security and Application Security in this post. It may have crossed your mind as to what the difference is. Good question, even folks in the industry have a hard time defining this. Here is my take — Product Security is a subset of an Application Security Program’s services that evaluates the security of an entire product from end to end. Product Security is squarely focused on the security controls as a feature set in a product. Application Security is a program which encompasses services, such as those that ensure security of software/cloud infrastructure/systems, are offered widely to a company. This makes certain that internal services and tooling that are not offered as a product are also covered. There may need to be a future post on this but here is a diagram that will hopefully illustrate the differences.
- Product Security Risks can arise at least as often as products develop and change. The AppSec team must play a key role in partnering with Product Development to handle them well.
- Create a Product Security Risk Template and store it centrally for everyone to reference. You may even want to make all or some completed Product Security Risks available to illustrate the practice.
- Have team-oriented Product Security Risk decision meetings. Maintain clarity & consistency in making sound decisions.
- Ensure any unmitigated risks are formally accepted and re-accepted.
- Allow time for AppSec to perform their services such as secure design reviews and pentesting before the product goes live.
- Understand how Product Security fits in with AppSec and leverage this relationship as a fundamental way to create trust with stakeholders.
Words of Wisdom
It should never be Product vs Security, but rather a trusting partnership where there is push and pull, but everyone is on the same side working together.
It’s so easy to get sucked into negative and closed minded thinking when dealing with Product Security Risks. It shouldn’t always be an all or nothing mentality. This is why having a template for the decision making process is so critical in order remove biases or emotions as much as possible.
The point of this, and all of my other posts, is that with a little help, anyone should be able to find the right balance and approach to AppSec for themselves. I hope you find value in these posts and more importantly allow for a conversation on how we can all get better at AppSec together!
“All you need to paint is a few tools, a little instruction, and a vision in your mind.” ― Bob Ross
If you are interested in how to build a security champions program, then check out my post How to Scale AppSec with Security Champions!
Contributions and Thanks
A special thanks to you, the reader. I hope you benefited from it in some way and I want everyone to be successful at this. While these posts aren’t a silver bullet, I hope they get you started.
Please do follow my page if you enjoy this and my other posts. More to come!