Resources Blog HID Global's three pillars of operational security

HID Global's three pillars of operational security

In view of the more frequent and more sophisticated attacks on the software supply chain, securing the software development life cycle (SDLC) has become more important than ever. But that's easier said than done. Manual security scans require far too many man-hours, are no longer fast enough and make scaling difficult. Automation is needed to continuously identify and remediate risks at every stage of software development.

With countless tools out there to choose from, complex processes and policies to take into consideration and need to get teams to get on the same page, what are the key elements that should be taken into account?

At the DevSecOps Leadership Forum in Paris, François-Eric Guyomarc'h explained the three pillars of operational security, as well as the challenges and best practices associated with them. François is the Director Architecture at HID Global, an American manufacturer of secure identity products.

François-Eric presenting at the Leadership ForumFrançois-Eric presenting at the Leadership Forum

Security at the core

As a provider for authentication, physical and logical access management, identity management and credentialing solutions, security is in his company's DNA. This applies to their software, access control, and identity products such as smart cards, readers, printers and RFID tags, and to the variety of different applications HID Global develops for all these products. And as different as these applications are, so are their security requirements. Embedded, mobile, cloud - when it comes to security, one size does not fit all.

"It's really interesting but at the same time a true challenge," François-Eric admits. 

Not surprisingly, the security measures along HID Global's SDLC are complex. 

Application security foundation

A triad of key pillars that make application security at HID Global work - and last: policies, experts and tools.

  1. A set of defined policies is needed to give direction. Without them, no one knows what needs to be done.

  2. But policies are only helpful if there are people in place who can enforce them.

  3. With increased focus on productivity, organizations are aiming to automate as much as possible. It is therefore crucial to select the right tools and to configure them with the right parameters to support and not overwhelm developers.

It quickly becomes evident that the equilibrium between them is as important as the pillars themselves. If one is missing, you won't get to the sweet spot of security being optimum. It's also key to have integrations with existing tools and project management practices to streamline the processes.

The three pillars needed to implement effective SDLCThe three pillars needed to implement effective SDLC

Policies: Make them practical 

From OWASP and PCI to CERT Secure Coding Standards, there are lots of standards to base policies on. Keep in mind that not all applications are equal and define security requirements for different applications, or "risk profiles." For example, a cloud application with internet access poses more security risks than an access token that has no connectivity.

Making your policies practical is key. This means asking your developers to use multi-factor authentication for each of their pull or push requests, for example. While this might seem great from a security perspective, it's not reasonable for a developer's day-to-day work. Overloading your team with precautions can become a productivity drag.

Lastly, leave sufficient time for implementation of new policies while continuing to reinforce while continuing to reinforce existing ones over time. Especially in face of the increasing number of policies, teams tend to forget.

Expertise: Involve people early

Policies are just words - you need people to implement them.

Instead of just dumping the final policies on them, involve developers and architects early in the definition process and build the expertise within the team. A great starting point is to make your architects security champions and have them apply the policies to their products. However, with these additional tasks, they can quickly become the bottleneck in the process.

You can avoid this congestion by offering your developers both generic security awareness and role-specific training (from cloud to mobile or pen tests) to bring additional security champions up to speed. Managers play a crucial role here approving time for training as well as budgets to enable their teams with tools and certifications.

Tools: Configure them to match policies

Systems and tools can help automate the process and save time, but only if they are configured to match the policies and don't bring too many false positives. Don't underestimate the overall cost: free versions might give great initial insights, but quickly reach their limitations.

It's also important to factor in costs for deployment, maintenance, and configuration and efforts needed for proper integration into your continuous delivery / continuous deployment (CI/CD) and with existing practices and tools. Integrating with JIRA, for example, allows you to track security issues like any other bug and manage them as tasks. These integrations are key to get the benefits of automation, to increase transparency, and to push adoption.

It's crucial to consider your choice of tools. It's easy to overload a process with unnecessary checks and analyses, slowing innovation, and decreasing adoption by your teams who are unable to see the forest for the trees.

Bridge the gap between security and development

Security needs to be integrated not only from a tooling, but also from a project management perspective. Involving development teams and security champions from the very beginning in the policy definition process will help bring the two perspectives together and create one list of requirements in one single log and one roadmap.

With this in mind, HID Global divides its software development into 3-month cycles. For each block, development and security teams are equally involved in defining the priorities and themes.

How to prove the business value? 

Training, tools, costs of integrations - more often than not you might get snap reactions from business owners when they see the resources required to implement policies. Help them understand that security adds business value:

  • Present concrete examples of recent attacks such as SolarWinds or Log4j,

  • Describe security projects in dedicated whitepapers and emphasize why security is important from a customer and industry standpoint,

  • Leverage positive results from pen tests and tool analysis.

If you are interested in learning how other companies bring policies, experts and tools together to secure their software development, read their stories.

Would you like to join the discussion, hear more best practices, or participate in one of our upcoming DevSecOps Leadership Forums? Check out our events schedule for your region and register now!

Picture of Karin Althaus

Written by Karin Althaus

Karin is a language, marketing, and travel enthusiast. As Field Marketing Manager at Sonatype, she specializes in raising awareness of DevSecOps best practices and open source governance across organizations in the North-Eastern part of EMEA.