James Thew - Fotolia

Adobe uses shared responsibility to meet security challenges

Adobe discovers ways of addressing security challenges of scalability, diverse technology stacks and business criticality

Adobe uses shared responsibility to address key security challenges, according to the company’s senior manager of secure software engineering, Mohit Kalra.

“Most companies face the challenge of having relatively small security teams because it is difficult to find and retain people with the necessary skills,” he told the Eema ISSE 2016 security conference in Paris.

Adobe addresses this challenge through appointing security champions in each of the product groups to take the pressure off the central security team.

This approach of sharing security responsibility is a strategy that can be used by any company, regardless of their core business.

Security champions in core business areas typically have more security knowledge than their colleagues and they help ensure security is a focus of the teams they work in.

“They act as the eyes and ears of the central security team and take responsibility of ensuring the baseline security requirements of the company are met,” said Kalra.

At Adobe, this means that security champions are responsible for the security training in their product group as well as the static code analysis procedures and security testing.

“This means the central security team have more capacity to focus on setting and updating security requirements, on threat modelling, on reviewing high-risk alerts and signing of products,” said Kalra.

“Instead of the central team being involved in every security task we set up the products teams for security success and make it clear that security a shared responsibility,” he said.

Security across products

In addition to addressing the finite capacity of central security teams, most companies are faced with having to ensure security across a growing number of different technologies.

At Adobe, this means having to maintain security across a growing and diverse product portfolio on the desktop, in the cloud and on mobile devices.

“This complexity can be exacerbated by mergers and acquisitions, where new products and services are added, without any headcount being added to the security team to manage it,” said Kalra.

Adobe tackles this by establishing for each product whether it is essentially a mobile, desktop or cloud application.

Some products are a combination of these, said Kalra, but by understanding what the particular security requirements of each product are, the baseline security requirements can be expanded to cater to those.

“For each of these, we have a set of additional steps that need to be taken to ensure that all security requirements of each product are addressed by catering for different technology stacks,” he said.

Because technology stacks are continually changing, Kalra said organisations should understand that their security practices – in the case of Adobe its secure product lifecycle (SPLC) – will also need to be updated continually in terms of tooling and checklists for new requirements.

Maintaining legacy products

Another common challenge facing security teams is finding the right balance between taking care of security for the latest and most business critical product and maintaining security for legacy products.

“While the business priority is adding new products and services, legacy applications cannot be ignored by the security team,” said Kalra.

“While it is absolutely OK to tune [security] for business criticality, I just feel that it should not be the first step in any organisations’ prioritisation process,” he said.

Adobe starts by defining its baseline SPLC and specialisations for services, mobile and desktop, but when new critical products are on the horizon, the security team starts doing deep threat modelling around them and bringing in third parties to do targeted penetration testing.

“This typically wins us time to give these new critical products the attention they require and ensures that issues do not begin building up,” said Kalra.

Other products that have high value due to their business criticality or the risk associated with them are also routinely monitored and tracked.

“Our chief security officer talks to our chief executive on a monthly basis and to the board on a quarterly basis to give them a view of the security of key products,” said Kalra.

“This means the backlog of open issues against these products remains visible so we are able to tell the executives how well the company is doing in terms of risk remediation and whether enough progress is being made, which motivates everyone to do well in security,” he said.

In this way, Adobe’s security team is able to tune its approach to business criticality, which means not every product gets the same amount of attention from every member of the security team.

“Essentially, we are able to give every product team some minimum guidance, but we are also able to up the security engagement, depending on how important or critical the product is,” said Kalra.

He reiterated that secure product lifecycles will scale only where there is shared responsibility for security, and that there is a need to evolve security practices continually in line with changing technology stacks.

Read more about secure software development

Read more on IT risk management