DevOps and Security

Nadeem De Vree, CCO & CIO, NN

content-image
The saying goes that “where there’s change, there’s opportunity”. And often this is interpreted to mean that there is opportunity for positive change. In a controlled environment, change is a factor that one can predict, react to and, relatively, easily adjust to. That’s a lab environment, not one in which we find ourselves. In business there are a lot of trends that are going on at the same time. Two of the largest are the move to a DevOps way of working, and a growing awareness that Security is now a business critical function.

DevOps is the process where teams are responsible for both the development and the operations part of an application. A continuous process that makes incremental changes to the environment seeking to increase and/or improve functionality.

On the other hand Security achieves its best results within a controlled or stable environment. Where the security measures adapt as technology advancements allow for more efficient protection.

It is this conflicting situation that most companies find themselves in, regardless of if they are financial organizations that are compliance driven or high tech/products companies that are more risk focused. Financial organizations need to make sure they comply with regulatory demands. They have a strong compliance based culture where any changes that could affect the reporting or stability of the company and its customers needs to be tested and documented. The result is that the fast paced DevOps way of working is slowed by a need to document and get the needed signatures and at times waivers.

Financial Organizations have a strong compliance based culture where any changes that could affect the reporting or stability of the company and its customers needs to be tested and documented

Companies are now realizing that there is a need to reassess how they deal with the compliance regulations put in place following the 2008 financial crisis. We see a trend that auditors and financial institutions are working together in assessing what is mandatory, and streamlining the process so as to create some more ‘breathing space’ for the DevOps teams to operate in. In parallel specialized IT security teams are being set up that are deployed to those DevOps teams that are working on IT changes that meet corporate requirements. The decision for these security teams rather than dedicated security individuals within the DevOps teams themselves would seem to be dictated by the scarcity of skilled security professionals on the market as well as a lack of work within the teams to validate the dedicated security professional.

High Tech and Products driven companies are moving away from compliance driven security and towards risk based security. Whereby the process is to determine the risk appetite of the organization and then translate this into policies and technologies. These companies are more often than not faced with a need to get products to the market sooner than their competitors. This places very different demands upon the DevOps process and the need to streamline the integration of security and DevOps; security by design. Ideally within these companies the risk appetite will be instilled within the companies ethics and as such with all the employees. The internal conflict here is between the need to create secure products and the need to be first to market. These companies have often given the security organization the ability to block the release of any product that exceeds the risk appetite of the company regardless of what the product owner might want. This approach results in a close cooperation between security, product design and the DevOps teams so as to reduce any delays later on in the process.

It is generally accepted that the DevOps way of working leads to faster results that are able to adjust where needed to meet changing demands, and as such this way of working will continue to move out of the IT/product development world and into the larger organization structure. Similarly companies are also aware that it is no longer a question if there will be a security breach but rather when and that it is therefore key to always stay one step ahead. Concluding that ideally security would be a standard part of the DevOps way of working. However as long as product owners push to reduce time to market or organizations are compliance, and thus administration, driven we will continue to see that security is experienced as an inhibitor rather than an enabler in the DevOps process. Despite this, companies are and should, continue to strive for a true ‘secure by design Devops culture’.

Weekly Brief