person typing on laptop

Vendor Assessment 101: The 3 Fundamentals of Operational Security

Banks and financial services providers are complex organizations that offer a multitude of appealing opportunities for fraudsters to breach customers’ data and financial assets. But while we often concentrate on what we can do internally to tackle this problem, including focusing on the types of fraud prevention solutions we can choose from, what about the way software is developed by the vendors we select?

Solutions are only as secure as the way they are developed. Traditional software development and manual security scanning techniques are no longer capable of consistently delivering secure solutions which can keep up with today’s fast-paced threat landscape. That’s why it is imperative to consider a vendor’s operational security and software development lifecycle during your selection process.

You are probably asking: how do I know if a vendor develops their software with security as a priority? What do I look for? What should they have in place?

The three fundamentals of operational security to keep in mind are: policies, expertise and tooling. Each fundamental is mutually important, meaning if one is not up to par, the others are ineffective. Let’s take a closer look:

Ticketing Sytem Operational Security • Automated • Guidance • Review relevance • Training • Used correctly • Configuration • No false positives • Relevant • Enforced • Homogeneous Project Management POLICIES TOOLING EXPERTISE IDE Identity Source Code/ Binary Repository CI/CD Pipeline PROVIDED BY SCALED AGILE

Fundamental 1: Clear Policies

While there are various applicable security standards, vendors need to enforce policies in order to comply with them. Therefore, it’s important that you consider the policies that are relevant to your business context and ensure they are applied by your vendor. Policies are there to help prevent coding and implementation errors, and your vendor should define policies based on differing risk profiles.

For banking and financial services solutions, you will want to know that your vendor is completing activities covering the full development lifecycle, such as threat modeling, code reviews, security testing and deployment, as well as proper incident response.

Aside from the direct security-related impact, having relevant policies in place is also important to the bigger organizational context. Without policies, engineers, developers and architects have no clear and consistent way to ensure that the software is secured throughout every step of the development process. Policies guide a clear direction, and quite simply, if they don’t exist, people don’t know what needs to be done. The consequences of not having them only worsen when team members leave or change teams and security falls apart. Therefore, your vendor should periodically review policies to ensure they are still relevant and in use.

Fundamental 2: Established Teams to Enforce Policies

It is your vendor’s teams of developers and architects who bring solutions to fruition, so it’s crucial that they are provided with proper training and certifications to do their job. Expertise should be built within teams rather than “dumped” on them. It’s important that security and key business area teams are involved in the creation and implementation of policies from early on, so that they are fully integrated as part of their role.

It’s no secret that enforcing policies is likely to place additional tasks on teams in the beginning, but instead of avoidance, vendors should alleviate any frustration by providing effective security awareness and role-specific training, such as cloud, mobile, pen tests, etc., before policies are introduced. After implementation, there should be continuous team training and relevant certifications to ensure that policy and security expertise is maintained as people move throughout the organization.

Without the right teams in place with the right level of expertise, a vendor’s tools will not be configured, used properly or taught correctly to other teams — deeming them impractical and a hindrance to security.

In general, the level of consideration and investment in a vendor’s security staff speaks volumes about the quality and continuous improvement of their software development and ultimately, the solutions you will leverage from them.

Fundamental 3: The Right Tools

A vendor’s establishment of tooling is an indicator of how invested they are in security. Having the right tools in place will enhance their ability to detect and respond to new security issues, as well as maintain the security of their solutions going forward. In addition, it also dramatically affects the overall efficiency and speed of development. Manual processes take too much time; hence, you should ensure the vendor is expediting them to help innovation move quickly.

Furthermore, a vendor’s tools should be configured correctly to match the policies they have in place, so that they do not cause issues — such as generating false positives — and slow down the whole process.

Piecing Everything Together

The winning combination of policies, teams and tools should be easily integrated within a vendor’s existing delivery and deployment process — for example with JIRA and other tools. Ensuring proper integration means that the vendor can comprehensively track security issues across their ecosystem and manage bugs or threats efficiently.

The entire development lifecycle should be managed with a focus on continuous improvement and constant delivery of value — for example using the Scaled Agile Framework (SAFe) with short product increment (PI) and suitable project management tools. Whilst innovation is undoubtedly a top priority for vendors during their software development lifecycle, they must still ensure capacity during their PI or cycles, to prioritize security in the products they develop. By no means should security be an afterthought. Instead, security upgrades and preventive measures should be integrated incrementally and not done all at once.

Read more about the solutions delivered by HID that help banks and financial services providers power trusted identities, with a focus on continuous value and unmatched security.

Francois-Eric Guyomarc’h is HID Chief Product Security and Privacy Architect. With over 20 years of experience in the fields of architecture and security, he’s responsible for driving security and privacy by design principles into all HID product development,  executing  the corporate-wide strategy to fulfill the responsibilities and expectations of the Product Security and Privacy Architecture Team. He has specific expertise in multi-factor authentication, single sign-on, identity, device and credential management with an extensive experience across banks, government and enterprise verticals.