Enterprises as modern software factories: Infusing security throughout the app dev process
The DevOps methodology is ready to take the next step in its evolution. The first instance incorporated an operational approach to application development to create in-house, custom apps in a fast-paced, iterative environment. The next step must now insert security at each point of the model.
It’s well known that using a modern software factory approach, like DevOps, can improve an enterprise’s overall speed and agility. The focus is on innovation and producing applications that provide a competitive edge and drive important initiatives. To date, security has not been a development consideration.
The rise of security threats, increasing complexities, and evolving compliance requirements for the protection and treatment of data mean enterprises must incorporate security from the very beginning of the design. Security can no longer be tacked onto the end of the process and run the risk of valuable data being stolen and the possibility of the organization losing critical personally identifiable information (PII), the loss of business, and/or incurring severe compliance fines for the loss of both PII and protected health information (PHI).
Most application developers are not security experts. To have them adjust their process to learn how to insert advanced security features into applications under development is not realistic. Therefore the notion of “shifting left” and adding security into the development process makes most DevOps teams flinch, and brings expectations that execution speed will be negatively impacted or completely undermined.
Why? Security adds complexity and requires additional knowledge and coding skill techniques that most developers do not have.
Unfortunately, in many cases, security is neither a part of development nor operations. The application may be developed and deployed, and only see involvement from the security team when something goes wrong, such as the discovery of a data breach or the realization that the company is out of compliance with the growing number of regional data privacy laws governing PII/PHI data protection, usage and privacy. These issues can be costly.
For example, the GDPR carries penalties of up to 4 percent of an organization’s worldwide revenue or $20 million euros, whichever is greater, for violations of its data privacy and usage requirements. In other cases, regulated industries must follow additional laws, such as HIPPA for medical or 23 NYCRR 500 for the financial organizations in New York. Enterprises may face other damages, ranging from other penalties, lawsuits and remediation costs to loss of customer trust and loyalty, and the application may be taken out of production, impacting various business practices.
The reality is that by not incorporating security in the process, time-to-production deployment will be lengthened and the risks to delivering proper functionality rise. When security comes as an afterthought or in the final QA of an application, the security team has to play catch-up just to review and analyze it. In particular, when the app requires access to production-level critical data such as PII/PHI, the security team has to sift through unfamiliar code to uncover potential vulnerabilities and understand how the use, transmission, or storage of data may put the enterprise at risk. The catch-up time, which is often considerable, could be avoided if security is integrated with the DevOps process from the beginning.
With all of this working against them a better—and increasingly essential—way for DevOps to remain relevant is to fully incorporate security into the entire process. Rather than be the “department of no” or the anti-DevOps force, security professionals can participate in the process from the very beginning to fluidly shape the design and deployment stages to meet security and regulatory requirements.
Ideally, the security team should work side-by-side with developers and business heads during the design step to review corporate goals and balance them with a mutually agreed upon level of acceptable risk. Risk will always exist to some degree, and the security people can help identify it while working with all constituents to achieve acceptable equilibrium.
Next, and probably most importantly, application developers must have simple-to-implement tools such as agents so that security features can be inserted into the application during the development phase. This allows developers to remain agile by keeping their preferred coding approach. It enables iterative development and continual testing rather than a QA at the end of the development. Such an approach ensures speed and efficiency and even, perhaps, some transference of skills and perspectives between the software developers and the security team.
Another important consideration is to take the human element out of the equation. Working security into the app development process through automation alleviates many concerns and possible disconnects. For instance, an application that upon deployment can automatically detect and activate relevant security policies, and/or advanced security techniques like encryption, protecting the application as well as the data produced and held in storage. Even after applications are deployed, configuration settings can be adjusted based on deployment scenarios. Automation allows the security team to apply these updates through the agents and have them programmatically deployed. Changes can be made even though development has long since moved on to other projects.
On the operations side, the security team can help optimize how and where encryption is performed, which data paths should be used or prohibited, and where data should be stored. The security team can decide if and how single sign-on might be incorporated and what other kind of authorization and access controls should be put in place. The team can also ensure that the application functions well with existing security infrastructure by adding acceleration offload capabilities as required.
Proper data treatment is especially important if open-source software or code from libraries and community portals might be incorporated. Having the data secured and inaccessible during the inevitable data breach means that security stays ahead of issues when subsequent threats and vulnerabilities might surface. History has shown that it can take months, if not years, for vulnerabilities to be detected, never mind the time delays incurred during patch development and testing prior to implementation. With the data properly secured, the security team can take the time to properly test and patch or fix a particular configuration without the development teams involvement.
Infusing security throughout the entire DevOps cycle is the next step for a modern software factory approach to in-house applications. Enterprises will quickly see that such a move will not only solve security issues, but also will result in a better development and deployment process.