In my Axway careers (six years in Integrator R&D and 12 years in Support’s Escalation Group), I witnessed major changes in Axway products and processes.
Axway products have evolved from standalone, to interoperability between Axway products, cluster installs, security aspects, and now DevOps automation and containers.
I have seen and was part of how Axway’s handling of security vulnerabilities evolved from humble beginnings to a wholly industrialized process.
Not every customer or Axway employee knows the whole details of our security vulnerability process, but at least (hopefully) they know there is one.
Hackers and security issues
Hackers and security issues existed before I started my IT career, but since it expanded widely, from the capabilities of attackers to image and economic impact of security breaches. Neither a serious company like Axway nor its customers can afford the impact of a security breach caused by wrongdoing (or lack of doing). My former manager started the first security vulnerability process on the support side.
At the same time, R&D was getting organized. A dedicated team, Product Security Group (PSG, nothing to do with the French soccer team) was formed.
Security Point of Contact
Every R&D product team has a dedicated Security Point of Contact (SPOC) and R&D organization has several levels of security training, including mandatory developer training, advanced training, and hands-on hacking sessions.
The Product Security Group provides tools, methodology, and training for Product teams to detect and fix most vulnerabilities (from classic tests to detecting unsecured third-party components), especially the major ones before a new release can be made available.
But I’ll focus here on detailing how vulnerabilities detected by our customers are reported. Practically, how does it work?
First, a customer finds an issue that qualifies as a security issue, either by itself or via one of the many companies offering penetration tests services.
A support case is open and handled quickly, much quicker than the average support case because we know there is nothing more important, after production outages than security issues.
Axway support
Support with the help of Escalation Group will review customer elements, see what’s already known, fixed, false positive, etc. Some false positives are dismissed but others may still be valid because whenever possible, the default configuration should be secured so that it doesn’t raise false positives. They may not be dangerous but still cause extra-work.
Otherwise, issues are sorted, grouped (by third-party component for instance), or split when a whole penetration test listing was provided.
Review and confirm…
From there, R&D product via its SPOC, occasionally assisted or substituted by someone from the Product Security Group, review and confirm issue as well as calculate CVSS vector and score.
The CVSS score helps sorting issues between low, medium, or high/critical and schedules the delivery of a fix accordingly (next release, SP, or a specific patch).
Some security issues with most common third–party tools (OpenSSL for instance), usually the issues with a nickname that make the news (Poodle anyone?) may also trigger a proactive analysis where all SPOCs will review and share details about if the product they are responsible for is vulnerable, as well as incoming mitigation.
Some of these situations may also trigger an Axway alert (both sent by mail and visible on the Axway support site) to inform customers if/when a fix will be needed and available.
Over the years…
Over the years, I have been involved in handling hundreds of security issues for various Axway products from support to R&D. I am not a security expert in the way I don’t know how to use Burp, Fiddler, or other security-related tools, nor am I a certificate expert.
But I don’t have to; my role is to provide information management. Security is one of the rare use cases where most of what we communicate has to be identified as coming from R&D and often support word alone will not be accepted by the customer as an answer.
Documenting issues, why they are valid or not, and the details of their resolution, will frequently be reused as many customers are likely to ask about the same issues over possibly several years and what’s in our information system, not even limited to CRM and defect system, is put to good use.
This may look like a no-brainer but isn’t and many times I witnessed people with less experience, even with product expertise and common sense, being confused about how to handle a penetration test report for instance.
Security is not limited
Security at Axway is not limited to what I describe above. We also have to protect our customer information, both in our information system or when sensitive data is handled by Axway products (messages processed, logs).
Further, you need to know how to react if a breach ever happens and development methodology and regular mandatory training (security awareness, HIPAA, etc.). Overall, the part of your security in our hands is well managed. Discover more information about Axway Security Compliance Program.
https://www.axway.com/en/customers/axway-quality-and-security-compliance?utm_source=devblog&utm_medium=blog
Learn more about the top 10 security risks that you need to know.