Let's develop best practices for security in DevOps
We've turned to DevOps and microservices because they've made it faster and easier to release and update applications. It's past time we developed security practices for them.
DevOps is a rising star, enabling IT teams to develop and implement code far faster than older-style cascade projects ever allowed. Security in DevOps, however, can be a bit of a problem.
DevOps, when implemented in a quick-and-dirty manner, allows developers to bypass many of the checks and balances that were nominally in place. Code is not tested as rigorously; as a result, this new code opens new attack vectors and compromises application security.
Indeed, advanced log analytics firm Logz.io recently asked over 1,000 IT professionals about security matters. In the survey, 54% of respondents said security was now meant to be a core part of the DevOps group; however, only 41% employed dedicated security professionals.
Further complicating the issue, 76% said that they either have not implemented or are still in the process of implementing a DevSecOps environment. And 71% admitted not knowing enough to be able to adhere to best practices for security in DevOps.
From my point of view, this gets even worse when you see that many security specialists -- and many of those tasked with training the next generation of security specialists -- are still locked in a past that will make them useless on the market.
How we used to secure applications
Historically, approaches to security have been led by challenge-response username and password pairs, along with database security protecting data from external threats. Both are walled garden approaches. Anyone who finds the door into a garden can roam around inside to their heart's content.
Another problem is that it is harder to define an application. The monolithic applications of yesteryear that carried out sets of processes around a central theme should be dying out -- helped or pushed by DevOps practices. DevOps can deliver on its potential only if teams use microservices -- small pieces of functional code that can be used multiple times in different environments.
This means teams need to write code in a manner where a calling service can identify it, make a request for an action and receive the results. By stringing together microservices on the fly, you can create a composite application that is far more flexible and that enables an organization to better respond to external market forces by changing processes in near real time.
Security of modern microservices applications
With microservices in DevOps, you create a completely different security environment. Challenge-response no longer works. How annoying would a composite application be if users needed to input username and password pairs every few seconds? Database security is a poor approach here too; each microservice may have its own data store, many of which may not be a formal SQL-based environment.
If you work in a DevOps environment, you must now focus on two new areas, as well as create microservices that are secure by design.
How? First, focus on ensuring that the person using the environment is who they say they are. This should not be the direct responsibility of each microservice. Instead, a corporate central service can provides this function. It could be a callable microservice for all other microservices to use, if you like.
The role of the DevSecOps team is to create an environment where information is inherently secure.
These already exist. Single sign-on (SSO) systems from the likes of Okta and Ping Identity provide systems that use two-factor authentication approaches to ensure that a user has more than a single set of identifiers to access any system. Indeed, SSO as a service is also available, so an organization does not have to implement its own central authenticator on site.
SSO systems then essentially provide a user with a token that they carry around as an identifier during a session. When dealing with highly secure composite applications, you may want to refer the process back to the SSO system at key points to get users to revalidate themselves.
Microservices should be written to make use of such tokenization systems. The leading approaches are SAML, OAuth and OpenID Connect.
Information security in DevOps
This brings us to the second part of security in DevOps: information security. In today's virtualized world, organizations can easily replace hardware and microservices. What really harms an organization is the loss of information.
Therefore, the role of the DevSecOps team is to create an environment where information is inherently secure. This relies on four techniques: classification, encryption, data loss prevention (DLP) and Digital rights management (DRM).
By classifying information correctly before it hits storage, DevOps teams can make decisions as to how important that data is and whether it should be encrypted or not. Then, DLP will stop that information from crossing over specific boundaries. This works with most information transfer environments, such as email, messaging, FTP and so on.
DRM then provides the means to govern data even when that information is on a platform outside the organization's direct control.
Consider what would happen if your organization's biggest competitor suddenly acquired one of your key suppliers. That supplier has information on its network that contains competitive value to your competitor. Through the use of DRM, that information can be encrypted or deleted. To gain access, the file must refer back to a centralized service -- another microservice -- that dictates whether that person had any rights to access and, if so, what those rights are. Block the entire ex-supplier, and no one within the new company has any access to your information.
So to move from DevOps to DevSecOps, take a new look at how to build composite apps and create an environment where there are sufficient available services for each new microservice to ensure that it is secure within itself and across the broader composite app.
