A large APAC based insurer had engaged a range of external software development companies and contractors to implement a company wide digital transformation program. After 4 years of 2 weekly releases a number of the applications were now complete and hence active functional development was no longer required.
Both reducing the size of the dev team and repurposing the remainder had significant cost benefits, however the dynamic nature of security bugs and newly published exploits meant that correspondingly reducing release cycles and came with unacceptable risks.
Given they already had RedShield’s generic threat protection service integrated into their delivery pipeline an upgrade to the microservices shielding service was considered as an alternative.
Through testing a range of application specific exploit scenarios RedShield was able to prove equivalency between customized microservice shields running on their proxies with software remediation within the code base.
We were also able to show rapid turn around in:
- Understanding the exploit methodology as described in the penetration testing
- Building a specific shield to address that exploit (typical through logic or content manipulation, not blocking)
- Assisting with exploit retesting and risk sign off
After functional development was complete we wanted to move the dev teams on to the next set of apps, but given their critical nature and the dynamic threat environment, we had to maintain agility. Without RedShield’s microservice shielding capability this really wouldn’t have been possible.
The core dev team has been now been reduced to less than ½ the personnel. Those remaining have been reassigned new projects. Applications beyond active functional development have been moved to 6 monthly maintenance release cycles.
If any application exploits are reported through either regular pen testing or relevant exploit publication (applied frameworks or application logic), the RedShield team is engaged to provide a shielding plan. The shields proposed are deployed, following customer change management requirements, in hours to days depending on their specifics.
When practical, the defect is then programmatically built into the next release. Once the new code release is deployed the shield is removed.