DevSecOps — The journey in Bank Mandiri
As one of the biggest banks in Indonesia, Bank Mandiri plays a significant role in embracing digital banking and supporting the growth of cashless society in Indonesia. To respond to the challenge, Bank Mandiri consistently put efforts to develop customer-oriented applications. As an ‘institution of trust’, Bank Mandiri believes that security becomes essential when it comes to software development. As such, customers (both internal as well as external) would have a high confidence level that the Banks applications they are using are secure and reliable.
Speaking of software development, it is interesting to find the fact that that SDLC has evolved so much that there are now hundreds of development methodologies provided in the field. Companies compete to adopt emerging software development methodologies, which offer better benefits in terms of faster time-to-market and greater flexibility, such as Agile and DevSecOps. Bank Mandiri is no exception.
Being a member of the Application Security team in Bank Mandiri, I am lucky to be part of a team implementing the DevSecOps methodology in Bank Mandiri. This experience has opened up an opportunity for me to embark on the Bank’s SDLC journey, from the long-standing Waterfall to the attractive DevSecOps and share the story. 😊
Although I have a deep interest in the methodology, I will not assess the pros and cons of each one and tell you the difference, simply because I am not the developer. Instead, I am the security guy. So, I will highlight the security aspects of each methodology.
Waterfall is one of the earliest Software Lifecycle Development (SDLC) model in software development. The model are straightforward and easy to understand. The whole process divided into sequential phase; The outcome of the one phase becomes the input in the next phase
Despite the strength in documentation and testing area, Waterfall has its drawback that security aspect only presents in the requirement building phase, and very little is put at a later stage of the methodology. Furthermore, the documents to be reviewed in this methodology is a lot, since the Banking Industry is a highly-regulated industry so that we have tight security requirements and regulations to follow. Security is less involved in the following phases until the days of testing come when the security guy comes with a big gun called “Penetration Test (Pentest)” which is pointed at the developer’s head, causing a severe headache for the developers.
Penetration testing (pentest) is a security test to find security holes, system vulnerabilities, and missing security requirements in the applications. When they are found, the developer must fix them, then are retested by the pentester. Otherwise, the applications are not secure and reliable. This process is quite robust and is meant to ensure the applications’ security.
However, a question arises: what if the applications must be deployed ASAP, or there is a constant change in the business requirementin response to the market dynamics, regulations, or the technology being used? If the traditional process is applied into such cases, it would be too late to find the security flaws, thus at the end of the development phase. As a consequence, the project timeline might be delayed, the pentest result turns invalid, or the resources are wasted. At the end, the Bank would lose competitive advantage nor comply to the regulation if it fails to cope with the rapid changes.
Agile comes to save the day.
Agile makes the development phase more fluid since all the requirements are cut into smaller pieces, creating a space to accommodate changes and more developer-friendly if there is an inevitable change in the middle of the process.
It seems perfect, right? At first, yes.
At a glance, agile practices improve the process of application delivery, making the SDLC more flexible and better-suited to cater business needs. Agile solves the problem that lays in the gap between business or user creating the requirements with the developer team building the product based on the requirements. Therefore, it shortens development processes because it emphasizes on iterative, incremental, and evolutionary development.
Oh wait, where is the security part?
Even though Agile allows requirements cut into pieces, the process is pretty much the same. Security team only involves in the phase of requirement gathering at the beginning, and testing at the end of sprint. As such, when there are security findings to be fixed a later stage, the project is at jeopardy as the cycle would go back to the development phase, thus lengthen the project timeline.
However, in Agile, gaps within the technical team still exist; Security issues are only the responsibility of security teams, while application functionalities are solely taken care by the developer and system’s performance and maintenance lays in the hand of operational / infrastructure guys. No wonder that in lots of Agile methodology stories, whenever a problem is found, there is always an endless game of blaming between roles (Developer, Security and Operational / Infrastructure). Fortunately, that is not the way we work at Bank Mandiri. We hold on to a principle: 1 Heart 1 Mandiri, that is banding together to provide the best for Bank Mandiri’s customer 😊.
So, what do we do to narrow the gap and share fair amount of responsibility between technical team? We implement DevSecOps.
DevSecOps breaks the silo that are often found among members of the technical team, introducing a paradigm in which developers, security, and operational become one single entity, therefore, building a solid project team.
The cultural shift
One good thing about DevSecOps is that it is not merely an SDLC concept. It also transforms the culture: the way of working, the way of thinking, and most importantly the security mindset, when carrying out projects.
Other than running security operations, IT security team in Bank Mandiri works closely with project teams (developers, analysts, and testers). In the old days, we casually received requests to review projects, created the threat modelling, and then came up with security requirements. The same goes with the testing process; the security team would get requests to perform source code review, vulnerability assessments, and penetration testing at the end of the project phase. The security team was in charge only when the project was in the phase of formulating the requirements and testing. Security tended to be security team’s responsibility only.
In DevSecOps, the whole game changes. The gaps within the technical team are gone, the wall is torn down, and the responsibility are shared. Now there is no silo amidst technical teams. Developer, Security and Operational teams work hands in hands since the very early process.
This new paradigm has impacts on the project structure & organization, including the security department. In particular, the way we work has shifted from working by project team requests, to becoming the project team itself. The popular term to illustrate this is “shifting left” as ‘left’ philosophically refers to a point where the project starts. It is translated to security team being actively involved from the beginning of the project until the project is complete. The security team is not an ‘outsider’ that hands in the security requirements to the developer and let the developer meet the requirements no matter what, but it is now part of the team that develops the products. In such methodology, development process is not merely about writing codes, but it also practices secure coding and incorporates infrastructure and security operations into the process. Thus, the product delivery and system maintenance would run in a smoother fashion.
The Technology Change
Talking about DevSecOps is also talking about Continous Integration / Continous Deployment (CI/CD). In terms of security, it means injecting security aspects throughout the process.
Particularly in testing, manual testing is no longer used; every security process turns into automatic one. Therefore, the tools or technology used to perform source code review and vulnerability assessment need to be adjusted.
In DevSecOps, source code review are carried out along with the developer using Static Security Acceptance Test (SAST) tools. We execute vulnerability assessments every time the developer build the project with Dynamic Application Security Testing (DAST) tools. Security team also secures the platform, ranging from virtual machine (VM) to microservices. Security infrastructure and operations area also reviewed: the design, the migration, and the maintenance. Those changes allow security flaws detected in advance, therefore fixes can be done at the earliest, and eventually the whole project can run efficiently. Products can be delivered to the customers much faster, reducing the time-to-market (TTM). From the customers’ perspective, not only they can enjoy a great product/service/application, but also a secure application. 😊
(To be continued…)
