To both enhance service and optimise cost of delivery a large US based healthcare provider had embarked on a full digital transformation program. Central to this program was cost effective delivery of new capabilities.
With the help of various consultants a CI/CD pipeline was established and capability started to be delivered.
Due to the confidentiality requirements around patient records security was central to the CI/CD pipeline design and tooling. Devs were trained in secure coding practices, code scanning and run time analysis tools were used to detect defects and remediate early.
Given these tools embedded to the left of the process a. cannot detect all classes of known vulnerability and b. that new classes are emerging all the time, the applications were also subjected to application pen testing and enrolled in a bug bounty program.
The problem with these last 2 vulnerability discovery methods is that:
- They occur either very late in the deployment cycle or even in production
- The nature of these findings is often devastating and requires urgent remediation
- Urgent action involves reprioritisation of work which reduces pipeline velocity and maximising velocity is the goal
The company was already considering RedShield due to the pre integration of a number of the tools required to the left of the security process and hence an a discussion was initiated about this problem out to the right
RedShield got the customer to submit some example challenging Pen Test and bug bounty findings.
On receiving the findings the following steps were completed in under 1 week:
- Shielding plans for all items were produced
- Microservice Shields were created or tuned to address findings (typically these are transformation shields where application behaviour or content is changed in a code object to stop the application from being exploitable)
- Some of the more difficult shields were demonstrated in a test environment and assessed for effectiveness
RedShield also showed the customer a number of techniques to programmatically bring the shields in and out of path as part of their automated CI testing.
With the devs unable to fix security flaws fast, I found myself in the position where I was unable to directly resolve significant risks in my risk register. All I could do was advocate with the dev manager and get him to ‘not be wrong for long’. With RedShield all of that has changed. I can now fix it for the Dev Manager or 3rd parties. I also have an alternative if their timelines or commercials are unacceptable
Given the solution:
- Removed the need for urgent reprioritization of dev tasks
- Could be integrated with their automated deployment tools
A decision was made to move ahead. Now, after 18 months of deployment the RedShield component is just part of their process. Pen Tests and bug bounty results are passed to both the devs and RedShield and a decision is made on who will address the finding. If RedShield short term then a story is also written for the devs to slot into their development cycle at a later stage.
With the success of the program a decision was made to place RedShield in front of all externally facing assets and expanding the microservice shielding capability to older apps without an attached CI/CD pipeline at all.
For these application RedShield effectively gives them a CI/CD capability for reported security issues.