Monday, July 1, 2019

Checklist to evolve DevSecOps from DevOps

DevSecOps, by definition, is an evolution of DevOps. The growing philosophy itself is not fully formed and leaves a lot to still be defined. For anyone to claim it is anywhere close to a fully-formed set of best practices or rules would be getting ahead of themselves and the philosophy. This should be expected as DevSecOps is relatively new. 
This is the nature of DevOps, in general — always improving and never stagnant.
DevOps, as a process, isn’t by any means ancient itself. It has been largely accepted as a means of facilitating cooperation between the various compartments in an IT outfit, compartments that might otherwise remain largely sealed off from one another. 
The development side of IT works directly with the operations side in a fully formed DevOps process. This allows coding and direct software development to work in unison with traditional infrastructural issues like device management, network upkeep, and help desk functions. 
DevOps is designed to allow these sides to meet, communicate and more easily improve upon one another’s work in an automatic and streamlined way. One important aspect that has been left by the wayside is security.
Security is an ever-evolving issue that refuses to be solved for any length of time. It is a headache that needed to be included in this DevOps process for lasting impact inside an organization.
There isn’t a better time to address security of a project than throughout the entire project.

Maintain the DevOps Mindset

At its core, DevOps is a business philosophy — a way of structuring and organizing the IT culture at a company. The big selling point behind this philosophy is that it helps create software, test it, and push it to market faster. While this is certainly true, it’s not the whole story.
Creating and releasing software quickly doesn’t mean much if the product produced is not of high quality. To ignore DevOps’ role in quality control would be failing to grasp its true importance and intention. Effective DevOps allows the development and operations arms to harmonize together and create high-level and quality controlled software as quickly as possible.
As DevOps evolved, which it is perpetually doing, it became obvious that these processes, services, and tools needed to include far more than just software development and operations management. With each new story of a massive data breach and its catastrophic consequences, cybersecurity swiftly became recognized as a critical part of any IT ecosystem. This realization led to DevSecOps.

Transition to and Embrace DevSecOps

The goal is to make security part of the development workflow.
As mentioned, DevSecOps is the natural extension of DevOps. The process is meant to do two things: It can either take the benefits that DevOps gives to the development and operations branches of your IT department and extend them to the security team or it can integrate the security processes that need to be done into the DevOps team. 
In DevOps, creating and releasing software quickly doesn’t mean much if the product produced is not of high quality. Does it mean much if the product produced isn’t secure?
Security was being ignored in a process where it logically should have been the main component. Companies truly could not afford to ignore this conundrum any longer. 
There are three basic ways of breaking downDevSecOps for any organization: 
  1. As a series of technological protocols, like multi-factor authentication or zero-trust, that you implement to secure your DevOps processes.
    Perpetual verification can get tiring but not allowing anything through without being checked is one of the few ways to stop almost every threat coming from the outside. This process allows threats to almost always be diagnosed from the inside.
  2. As a series of processes dictating when and how to apply security checks to everything that you do in DevOps.
    Specific scenarios call for more security checks more than others. Identifying and laying out which process needs more security attention than others allows most security threats to be rooted out.
  3. As a philosophy of cooperation and shared ownership in which members of your development, operations, and security teams collaborate together, each taking responsibility for some things that would normally be outside of their purview. 
    As the basis of DevOps is cooperation, this is the most important aspect of DevSecOps. Bringing another focal point into the fold will almost certainly be met with resistance from team members but the long term benefits make it worthwhile.
These three ways of looking at DevSecOps ultimately improve cooperation among the disparate IT team departments. In particular, the transition from DevOps to DevSecOps improves the team’s ability to detect and mitigate threats earlier in the development process.
Subscribing to all three options ensures that no stone is left unturned and leads to the best results in terms of maintaining or even improving current development goals while addressing the security issues that need to be addressed. The goal isn’t to tear everything down. The goal is to empower. 

Use the DevSecOps Philosophy in Action

DevSecOps isn’t possible by going about normal day-to-day DevOps processes. You can’t tell team members to just be more mindful about security and expect better results. Security team members can’t randomly jump into the development process and expect to make friends with developers.
How, then, does DevSecOps actually work in practice? The philosophy of DevSecOps is one thing, the practice of DevSecOps is another. In essence, there are three major elements to this new iteration of DevOps:

Microservice-Based Infrastructure

Dissecting your entire infrastructure can be a clunky and unwieldy process. Once it is actually accomplished, your whole process — developing software, configuring infrastructure and running security checks — is broken up into tiny parts, each with specific individual functions. This enables your infrastructure to turn into a well-oiled machine.
After everything becomes hyper-specialized, segmented and well-defined, it becomes easier to monitor each step of the process and make necessary upgrades on a gradual level.
This also allows each individual or small team the ability to claim a process as their own. The blame game will not rear its ugly head and team cooperation will reach higher levels. DevSecOps relies on team cooperation to the same degree as DevOps, possibly even more.
Again, the goal is not to tear everything down. Dissecting an entire infrastructure is done on paper. Once dissected, a company can figure out how to specialize and segment in an efficient manner that will cause the least amount of disruption possible in practice.

Continuous Feedback

To start, tearing down the infrastructure requires feedback. Each team and possibly each team member should have a say on the hypothetical dissection of the organization. Starting from ground zero on a feedback-based system is the ideal approach.
In a DevSecOps-tuned environment, developers receive continuous feedback regarding the state of their systems. This constant flow of updated information lets your team know where it stands in relation to security threats. With security blended into the mix, everyone gets the latest information and can efficiently implement necessary security patches and updates.
Without continuous feedback, new processes are daunting to individual members of a team. Continuous feedback is necessary to keep your I.T. team focused and inspired. When a task has been completed the same way for long periods of time, sometimes years, continuous feedback is necessary to achieve efficiency and proficiency. 
A key detail that must be kept in mind: feedback does not only originate from management. Feedback should be oozing from every team in the DevSecOps process. If the team is truly segregated in development, security, and operations — each team will have responsibilities to the other teams and should be providing feedback back and forth multiple times a day.

Automation

Artificial intelligence and machine learning both have the potential to streamline almost everything, reduce human error, and dramatically speed things up. The kicker is that it has to be properly applied to your security checks and other processes. Automation is well and good but challenges arise when it is implemented improperly.
Most DevOps processes instill a hefty dose of automation. Teams that are starting from the ground floor should start slow to avoid overwhelm and confusion among the team. Automation does not only mean AI. Implementing the use of the highest quality of basic software  — such as a malware scanner, VPN, and two-factor authentication tool — among your team can help shore up security practices immediately.
If developers must go out of their way to initiate scans, there's a good chance they will abandon the scanning tool. Two-factor authentication is already adding a small time gain on a task and should be automatic when accessing anything. A good rule is to not annoy the developers. 
In an effort not to overthink basic security and think of automation as a complex tool filled with advanced AI, the basics shouldn’t be ignored. Automation does include advanced AI a lot of the time. However, in simple terms, it is taking a task that took time and making it so that task can be accomplished without the time it used to take.
After the basics, the assistance that AI and ML provide in cybersecurity is especially invaluable, as they not only automate basic and essential security protocols, but can actually learn, evolve, and adapt to newly emerging threats.
DevOps tools have been around for a while now. Tools specifically created for DevSecOps exist but come with criticism. Some call DevSecOps tools DevOps lipstick on an old pig. Patience should be urged to the burgeoning DevSecOps community as new tools will come with time.

Train Developers on Secure Coding

The beginnings of DevSecOps aren’t concrete but the origins can be vaguely traced back to the simple phrase of security as code. The issue is that security as code isn’t the first thing learned by most developers.
Retraining an entire development team on secure coding isn’t just a challenge in terms of retraining — it’s expensive. Having the time and money to go through this training is rare. It is necessary to ensure a smooth transition from DevOps to DevSecOps.
The main issue is that developers don’t know or think that there is any issue with their code. Security as code usually isn’t the first thing a development team worries about. This needs to change for the DevSecOps process to take hold. 

Avoid Difficulties Transitioning to DevOps or DevSecOps

Though the advantages of effective DevSecOps, both in terms of quality control and increased cooperation and efficiency, are immense, DevSecOps is as much about people as it is anything else.
Even on the best teams, people can sometimes be difficult. Introducing your people to a new way of organizing how they work together — one significantly different from the way they are used to working — can create friction in the following areas:
  • Learning to accommodate developers set in their ways and resistant to large-scale reorganization. Implementing DevSecOps reduces error in code but this can be met with resistance from the people actually implementing the code. This can be seen as not trusting the development team and met with resentment.
    Resolution of these types of issues are done through communication and compromise. Something as simple as choosing a hosting service can be achieved artfully. A developer may want to use a “developer cloud” hosting service, ie one with a developer-friendly product ecosystem, such as Salesforce-owned Heroku or the widely-loved DigitalOceancloud hosting.
    Ensuring each service a developer wants to use is secure gives the security team more work. This may lead security experts down the path of choosing a service that is tried and true. Performing a security audit on a specific developer-centric service and going with said service. is one way to achieve compromise. 
  • Trust issues between the different arms of your IT department leading to less-than-ideal cooperation. Similar to accommodating developers, each column of an organization has opinions of the other teams. Bias can lead to a member of the security team not trusting a developer or a developer not trusting someone dealing with infrastructure processes.
    These problems aren’t new to DevOps, and incorporating another team can lead to more. This is where cooperation and team members from different disciplines working side-by-side comes into play. Integrating members from different teams into new crossover teams leads to community.
  • An over-reliance on AI and automation that allows human diligence to slip. With DevSecOps gaining steam, automation software is running rampant. Listen to any of the big names in DevOps give a presentation and you will be met with warnings of over-reliance of automation. One day, this whole process may be done by machines. Humans are still the movement machination of the DevSecOps process as it stands in the present.
    Automation must be done slowly and carefully. If one piece of automation falls apart, the whole system is compromised. Start with the basics and move from there.
These are difficult problems that can be overcome. Lack of trust and poor collaboration between departments is precisely the kind of thing that DevSecOps is meant to overcome. Given enough time and persistence, the requisite trust should emerge naturally. A tried and true strategy to implement new processes is to ease the team into the DevSecOps transition in gradual stages to avoid overwhelm. 

Inspecting Vendor Relationships

With security part of DevOps, preventative measures are easier to implement. It’s the difference between upfront inspection and constant vigilance or waiting for chaos to break loose and only then (too late) trying to fix the problem.
In today’s intertwined internet, substantial security risk comes from third-party partners who provide services and share data and resources with your organization. Your company and network is only as strong as the weakest link. A recent example, this one related to hosting service, is the Google Cloud outage that took down large chunks of the internet, and we mean large.

For perspective, let’s consider the effect on Shopify. The outage stopped sales dead for 800,000 stores in 175 countries for seven hours because the entire Shopify network is centralized with one host (Google Cloud) which obviously did not have a good backup plan. Most scary for those entrusted with securing sites is the reality that the outage could have been a hacker attack in which Google’s servers were forcibly taken offline while malware roamed amongst customer data of the affiliate stores scooping up whatever it could find.
Incidents like this put an intense focus on the uptime/downtime of hosting providers as a critical cybersecurity metric. You need to know your provider’s numbers. According to a recent review of web hosting uptimes, anything lower than 99.9% uptime is unacceptable for small businesses, let alone enterprises like Shopify on which hundreds of thousands of SMEs rely. 
The preceding example of the danger inherent in a vendor relationship is just that - a solitary example in a universe of opportunities. Think of every vendor that your website relies on or allows access to. Any of them could be a serious security problem. Are you ready for it?

Understand the DevSecOps Rules

To achieve the highest levels of productivity while using DevSecOps in your organization, try the following:
  • Integrate best cybersecurity practices for everyone from the beginning, like updating software and hardware regularly, penetration testing, and mandatory employee training on VPN best practices(virtual private networks) any time they connect to the internet. 
  • Prioritize security. Don’t let human error or carelessness be your undoing. The reason DevSecOps exists is that human error happens. The goal is to limit the number of errors and place protocol in place to catch the error after it occurs.
  • Monitor all software and check code continuously so you can patch security holes and aim to stay one step ahead of hackers. This includes implementing code dependency checks, such as the OWASP Dependency Check, on a regular basis.
  • Break tasks up into manageable bits. The smaller and simpler each step is in an overall process, the more likely it is to be done correctly.
  • Set up one-click compliance reporting so that you can have a clear log of every step in the software development process.
  • Encourage members of the different arms of your IT department to keep in touch and discuss their concerns. Ensuring team leads talk every day can be as drastic as enforcing mandatory meetings between different arms of the process.

Grow With a New Community

DevSecOps going mainstream is what every proponent of the process envisioned. A burgeoning community is placing itself at the forefront of organizational innovation.
DevSecOps Days is described as a global series of one and two-day conferences helping to educate, evolve, and explore concepts around developing security as code. As the movement grows, the ability to learn and improve within a community grows. 
As the movement grows, more organizations will sprout up with more events and learning opportunities for entrepreneurs, small businesses, and large organizations alike.

Time to Evolve

Today’s reality is that cybersecurity threats are everywhere. Any organization that intends to survive and thrive online needs to be ready for them. A major part of this readiness is to stay on the front lines of DevOps thinking, which is DevSecOps. 
This philosophical shift makes sure an organization has the proper protocols in place to assess, prevent, counteract or repel threats efficiently. Proper DevSecOps implementation might be the most important thing you do this year.

No comments:

Post a Comment