Image
- Where do you integrate security in the process chain? Traditional IT models placed security at the end, separating it from the rest of the process chain. This turned into a tedious task when any issues were detected at the security check, and it had to be rechecked by the development or testing teams. The process consumed time and resources, eventually impacting the time to release or market.
- Who will take the responsibility? Developers or Operations or DevSecOps or any other dedicated Security teams? Worried at the delays arising out of traditional IT security models, firms decided to have security an integral part of the entire process chain.
- Are there any tools for that? Next in order was the search for tools dedicated to or supporting the security mechanism in the process chain.
- Above everything, who is the key stakeholder? People or technology? Twenty-four percent of IT business leaders surveyed under the 2019 Container Adoption Report say application security is the responsibility of teams associated with or falling under DevSecOps. While 47 percent of them feel that this is the sole responsibility of DevSecOps teams, 57 percent of them in security roles believe core ‘Security’ teams are the responsible stakeholders.
Image
1. Security should be application-centric.
This is crucial when dealing with cloud, especially the ‘hybrid cloud,’ where network layer undergoes abstraction giving the infrastructure security control to the service provider. Remember that applications are something that represent and run your customer and partner-facing operations. So, building an application-centric security mechanism is very important considering the growing volume of apps, frequency of updates/changes to the existing apps, increased connectivity involving multiple partners across the enterprise and more.2. Security should be accurate.
You might not have time to recheck when releasing thousands of codes on a regular basis. Once done, it shouldn’t demand recheck. This comes by cultivating security awareness across the process chain and in every action the teams take. Every team involved should be aware of potential security threats. Enforce strict policies for effective implementation if required but make sure not to increase complexities.3. Security should be on record.
This helps understand or track organizational spending on security infrastructure, as a whole or on release-basis. A perfect program management plan helps achieve this goal by ensuring that security is in place and all the required specifications are perfectly documented and met.4. Security should be customizable or personalized.
Every microservice or application cannot be the same and has its own set of features. Teams should clearly understand exceptions and necessary measures to be taken. Try to keep it simple, straight and process-oriented.5. Security should be at high speed.
However, it should not be in a position to take over or slow down the front-end process in a DevOps process chain.6. Security should be scalable.
‘Security-as-code’ works well for driving innovation. It should be scalable enough to deal with unexpected/sudden errors that can arise out of fast-paced development process. ‘Security-as-code’ works well for driving innovation.7. Security shouldn’t be a hurdle for developers.
It should, in fact, support developmental efforts as the Dev teams moves forward in the process chain.8. Security should be a well-balanced factor.
It can’t be everything or nothing and shouldn’t even be a trouble to the existing process chain. The core job of security is effective management of risks. That’s why the security teams should be integrated into the DevOps process. Solutions like DevSecOps paved a way for DevOps security by offering the due scope for end-to-end integration. However, the above prerequisites are key to designing a successful DevOps-based security strategy – an effective security strategy backed by strong fundamentals is always favorable.About the Author:
Image
