Making Security an Integral Part of DevOps

In the rush to innovate, steal a jump on the competition, and bring new software products to market, enterprises have embraced the concept of DevOps: the peaceful co-habitation of Development and Operations, for more effective co-operation between the two.

 

But this competitive frenzy often overlooks a vital aspect: security.

 

In this article, we’ll look at ways in which security may be integrated with DevOps procedures, to benefit the enterprise as a whole.

The Case for Integrated Security

 The DevOps approach to developing software focuses on rapid application development, and the frequent roll-out of new releases – achieved through a harmonious mix of development, operations, support teams, and testing. New iterations of software may be prompted by feedback from users, configuration improvements, changing business requirements, or other criteria.

 

In any event, alterations are made and tested in a staging environment which closely resembles the production floor, and pushed out as quickly as possible. Testing is an automated process, carried out on small modules of the software, at unit and integration levels.

 

Yet traditionally, the testing of code for security issues and vulnerabilities has been sidelined – a process pretty much tacked on at the end (i.e. just before a new release is rolled out).

 

But if major security flaws are detected, they can either block a release altogether or (if ignored) lead to the roll-out of a version which has the potential to flop spectacularly in the wild, leading to user dissatisfaction, unchecked vulnerabilities, damage to a company’s reputation and customer loyalty, possible legal actions or compliance issues, and subsequent loss of revenue.

 

A compelling argument for somehow working the security testing and monitoring element into the DevOps software development model, earlier on.

How It Might Work

 Existing DevOps policies already offer some clues. In many organisations, tools are employed to run static code analyses, rather than unit testing after each code commitment. Developers receive rapid feedback on code which is confirmed to perform its stated function – and to have potentially greater security. This occurs in the deployment phase.

 

Monitoring tools are employed during production – and among these, dynamic security tests could easily apply. Ideally, these should be automated, and available to developers on demand.

No More Roll-backs?

 In a “traditional” software development environment, if flaws come to light during production, code can be returned to the lab, fixes applied, and a refreshed version is rolled back into the production environment. If this improved model also doesn’t work, the process can be repeated. This might take days, weeks, or even months.

 

DevOps doesn’t do “roll-back”. Rolling forward is the key to rapid application development and deployment. If fixes are required, they can be applied to the next release, within the space of a few hours. In a similar fashion, security patches under an integrated system can be pushed out to production quickly, and with a minimum of fuss.

Working with Compliance Issues

 The situation becomes more complex in environments which are highly regulated, and have both internal and external requirements which must be met to ensure regulatory compliance. For such enterprises, monitoring (including security monitoring) is an ongoing process, which can involve significant paper trails and interaction with third-party consultants and agencies.

 

Yet it is feasible to adapt the DevOps model to fit, in these circumstances. For example, it’s possible to enter agreements with regulatory authorities to change the audit classification of infrastructure improvements brought about with automated tools – which would exempt such alterations from the approvals required for changes made by hand.

The Role of Big Data

 Monitoring, testing, configuration databases and log files can generate a ton of data, within a production environment. Aggregating this information in an easily accessible repository and applying Big Data analytics to it can yield insights which not only optimise the software development process, but also enhance its security.

 

In the Agile software development model (of which DevOps is often a part), small changes are made to the code, in very short time periods. With the potential to roll out new releases to software on an hourly basis, the burden of testing has to be accelerated to keep up.

 

Big Data analysis can reveal which software modules have the greatest potential for failure, or vulnerability to security issues. These insights can provide a road-map for targeted testing of only those aspects most likely to be of concern – significantly reducing each test cycle.

 

And results yielded from automated testing across banks of servers over longer periods can throw up valuable data which can be analysed to identify target areas for surgical testing, in the future.

“DevOpsSec”, Anyone?

 There’s already talk of “DevOpsSec” – the natural evolution of the DevOps philosophy, which includes Security as an integral part of the mix. Having security officers working alongside their colleagues from development and operations is seen as a hedge against the traditional conflict between advocates of rapid application development and security testing – the voice of caution which can bring the whole fast-track process to a shuddering halt.

 

As with DevOps itself (which didn’t take off immediately), this will require a change of mindsets, procedures, and working practices, by all concerned.

A Strategy for Integrated Security

 1. Appoint a Security Officer, for each DevOps team. He/she will bring a security perspective to each discussion the team has, and help in making security tests, monitoring and best practices a part of the development process, from the start.

2. Encourage the various departments to learn from each other. Testing and compliance are fine, but the Security Officer must also learn the ins and outs of the software development process. DevOps should also become aware of the mindset of the security operative. Shared experience and knowledge will lead to better collaboration, between team members.

3. Allow some give-and-take in testing policies and metrics. Large-scale security flaws which could be application killers should be given precedence over minor issues that could be patched, later. Security should also set up some measurable standards by which the vulnerability of released versions of the software may be readily established.

4. Automate security testing, and include it early in the development process. If a security flaw isn’t spotted early, it may lead to nasty shocks, further down the line.

5. Use Big Data analysis, to identify vulnerabilities, and optimise testing. Analytics should reveal which types of code are most vulnerable, and should be tested more rigorously. Insights may also show which team members are throwing up the most security issues, or are not performing enough testing.

 

Ultimately, good security throughout the development cycle translates into good-quality products. So integrating security with the DevOps policy makes good business sense.