Recently I’ve been thinking about the relationship between the different teams within an organization – development, application delivery and security. Too often, these teams operate in relative isolation from each other. More and more, I see developers and application delivery teams taking advantage of the speed and flexibility offered by the DevOps framework, deploying new applications and updating existing ones more rapidly than ever before. Yet, in many organizations these processes are not being done with the involvement of IT security teams. All too often, the security team is simply expected to come in at the end of the development process, when the new application is ready, and simply sign off on, or approve, changes that they weren’t previously aware of.
In other words, these teams are working as if they’re on separate, unconnected islands: and as the speed of application deployments increase, so do the tensions and potential conflicts between the teams. Security teams may not be aware of exactly what the development team is doing, nor have visibility into the development processes, yet they are still required to report on and take ownership of securing the new applications being developed. And of course, any changes to existing applications, or new applications being deployed can have a significant impact on the organization’s overall security and compliance posture.
If security teams can’t get a complete, unobstructed view of their organization’s overall security status, they cannot easily identify emerging potential – or actual – security vulnerabilities, nor easily assess the business’ overall exposure to risk and ensure compliance. So how do we introduce the necessary checks and balances to ensure that DevOps processes are not rapidly introducing security problems; and equally, to ensure that security is not stepping on the brakes and slowing down the organization’s agility? How do we build bridges to connect the respective teams’ islands?
As we detailed in one of my previous blogs, a security policy automation solution that supports the DevOps methodology is essential, as it enables teams to automatically and easily adjust and migrate the relevant security policies when moving applications from development to test, to production.
The same solution also plays a key role in providing the necessary visibility and control of security across the organization’s entire environment – no matter whether in development or production.
Using solutions such as AlgoSec’s, security teams can be notified when security policies are changed for an application that is being prepared to move from the test environment to production. Security can then assess if, and how, these changes will impact the rest of the enterprise’s network. Moreover, developers can also use the solution to evaluate the effect of planned changes on existing applications, to ensure that they continue to run smoothly, and that the changes do not create unexpected ripple effects on security in other interdependent applications.
Furthermore, as security teams are responsible for compliance across the organization’s entire IT estate, an automation solution gives security teams the visibility and the controls they need to be able to assess and report on the organization’s overall risk and compliance status – across all environments.
In conclusion, baking security into DevOps processes does more than simply improve security and cut the costs of fixing defects at a later stage. It helps to build bridges between the development, application delivery and security teams within an organization, enabling them to collaborate easily and more effectively, and strengthen the company’s security posture overall. After all, no team should an island.
Receive notifications of new posts by email.