Story
In our Organization, we give high importance for securing an application. We have our Information Security team to guide the teams on developing secure applications and helps to mitigate the risks in the future. Based on the working model of the team, security controls may vary. We had a list of controls to be implemented in our application.
We had already planned priorities in our bucket. Comparing the project priority and security, which one takes the first place? Actually both. After many sprints we came a long way in the area of security and I would like to share some aspects of how we as a team we found a way to balance both priority and security.
Definition of Done
Instead of creating tech debt cards after releasing the feature to implement security, make the security checklist as part of story development and include security in the definition of done. How can we find the security areas to be focussed on at an earlier stage even before delivering the feature?
Threat Modelling is here to save the day.
Threat Modelling in simple words: put up the architecture diagram, brainstorm as a team to find out what can go wrong, analyze the risk and create a plan to resolve the issue. Threat Modelling should be short, frequent and should have an action item at the end of the meeting.
Automatic vs Manual
Say we have a security control to rotate(Change the key) user credentials for a service account after ~90 days. The team may suggest we rotate it and update the credentials manually, which will be a simple activity.
But in that case it is not a one time activity and we have several service accounts which will take considerable effort. Instead, if we put the same effort in creating an automatic job to rotate the keys, it can be used for all the service accounts and going forward the effort will be always minimal.
Visibility
Instead of bringing the controls out of the blue on some sprints to the team. Bring the visibility from earlier either through a dashboard or a weekly notification.
You can create an automatic job to scan for the vulnerability in each application. Checking frequently the status of the job is a practice to be followed. Instead, share the results automatically in the chat channel of your team when there is a critical vulnerability.
In VCS like GitHub, you can config the dependabot which alarms you when there is a vulnerability in any of your dependencies.
Integrating tools in pipeline
Some controls play a critical role even before the application is released. We use terraform for maintaining the infrastructure. How to find the threats in the infrastructure even before the infrastructure is deployed?
To find the threats and to know the impact of the threat, we have integrated tfsec in our system. Also helps you to mitigate the threat. There are various tools you can integrate in the pipeline to find the threats in the dependencies, enforce code standards, scan for accidental secrets being pushed into VCS.
Summary
Team needs to agree on the fact that securing the application is not a one day activity, it should be considered since the initial sprint. Everyone should be willing to take ownership on making the application secure.
