- Marriott (500 million affected) – Credit cards, passports and customer addresses were all fair game in the second largest consumer data breach on record.
- Quora (100 million affected) – “Quora, who has my data?” The bulk of customer data stored in Quora’s systems was harvested by malicious actors, ranging from user credentials to imported data brought in from linked networks.
- Facebook (87 million & 29 million affected) – These overachievers clocked two major breaches with Cambridge Analytica using their goofy personality app to rake in millions of user profiles from people the app installer were friends with. In a separate hack, Facebook access tokens were compromised allowing intruders to run roughshod across user accounts.
Source: Business Insider
These are just a few of the security breaches that stole headlines in 2018 as hackers continued their relentless mining of corporate networks. The average cost of a data breach is projected to cost a corporation $150 million in 2020 with the global hit spiraling upwards to a whopping $2.1 trillion yearly. That is to say nothing about the sizable PR hit a company takes when consumers wonder if it’s still safe to hand over their credit card to such a careless organization. Anyway you spin it, hacking is serious business that can be devastating to the bottom line. A practice called SecDevOps has cropped up in recent years, helping fortify corporate systems by putting security at the forefront of the software development process.
How is SecDevOps Different from DevOps?
Corporate America has bought into DevOps in a big way. According to Statistica, 77% of companies had adopted DevOps to some degree in 2018 with 17% saying their entire company has embraced DevOps. This represents a 7% jump from the year prior. You only have to look at these numbers to see why business has gone gaga over DevOps.
- 63% have experienced improvement in the quality of their software deployments
- 63% release software builds more frequently
- 55% have noticed an improved cooperation and collaboration of their team
- 38% have reported a higher quality of code production
Before DevOps, developers and IT/Ops teams led a contentious existence where those who created the code were walled off from those who actually deployed and supported it. With often divergent objectives and goals, the two groups had little reason to work together for the common good. In the new DevOps reality, collaboration and automation are key as teams are integrated around a common purpose. Human errors are reduced and the speed of development and deployment are increased through automated testing, continuous integration and delivery. DevOps is a cultural shift where project teams play the role that functional teams used to occupy. These teams can include everyone from the project manager and developers to the QA team and operations. This rapid, agile development environment leans heavily on automation to get software out the door quicker with less bugs. Yet for all the benefits continuous integration and delivery provide, we are also potentially bringing security vulnerabilities to market faster than ever before.
SecDevOps tries to patch this ugly reality by making security an integral part of the DevOps process. For too long, security has been treated as a luxury that the relentless march of progress can not stop for. Its a priority that is always getting pushed aside for another day. Just ask Equifax how well that worked out for them. We have to get out of this mindset that security is not every bit as essential as project planning and quality assurance. SecDevOps strives to make security awareness seep into every aspect of the team from the culture all the way down to the build pipeline. By carefully cultivating a security mindset within every team member, the group is constantly taking steps to ensure a secure feature set is making its way to release.
SecDevOps vs DevSecOps vs DevOpsSec
In some circles, these terms are used pretty interchangeably, but in actuality they pack a vastly different meaning depending on where you stick the Sec. DevOpsSec is more of a bolt on approach where security swoops in at the last second to verify that software, poised for production release, is clear of vulnerabilities. It’s a challenging piece to try to tack on at the last minute since most programmers don’t have the proper tools or requisite security knowledge to ensure that their code would clear this final hurdle. The security check normally results in delays or releasing software that has known security issues with the promise to fix them in a coming iteration. In this less than ideal scenario, developers and ops are in constant conflict with security professionals since security always serve as an ominous blocker, threatening to derail a release.
DevSecOps is definitely better but suffers from a lot of the same pitfalls that plague DevOpsSec. With DevSecOps, security is brought into the mix earlier, but usually the development team is not afforded the know how to combat security flaws as they develop or access to the necessary tools to pinpoint flaws. This model results in added development cycles as the tail wags the dog in a lot of respects.
SecDevOps is really the model organizations should strive for. By integrating security professionals as part of the DevOps team, these individuals can properly train developers, project managers and other stakeholders to think like hackers and view changes through the lens of the potential vulnerabilities they might create. Developers are exposed to security tools that can be included as an automated part of the build process, uncovering vulnerabilities no different than finding a critical bug. This heightened awareness empowers all team members to be security conscious and not just the designated security professional on the team. With SecDevOps, security is brought in at the earliest phases of project planning and carries through to post-release. It fits into the same agile, iterative approach many organizations have become so comfortable with. In SecDevOps, security never has the chance to becomes a disruptive force since it is a constant throughout the project life cycle.
Security Professional Role in SecDevOps
In addition to training the DevOps team on security best practices, security engineers highlight risks within a system and help limit what makes it out to the prying tools of hackers. These professionals build threat models, assessing how a hacker might exploit a new feature. They create penetration tests to see where a SQL Injection or a Local File Inclusion might take root. They define security policies for developers before a project ever begins and shows them how to use testing tools to identify issues as another step of the continuous integration and delivery approach. They run constant automated scans against user interfaces to surface hidden risks. They also handle audits and compliance monitoring so the organization doesn’t run afoul of PCI and GDPR. They are the good guy hacker trying to save the company from becoming just another cautionary tale
DevOps has reached the maturity level where SecDevOps needs to become the new standard. DevOps has realized the promise of automating software builds, bringing harmony to IT teams and improving the end product which squashes more bugs and brings more coveted new features to the end user. With all the advancements continuous integration and delivery has brought us, we can not ignore the fact that opening up security holes in our applications is inevitable. You have to ask yourself, “Is this the build where hackers infiltrate our system and make off with terabytes of sensitive customer data?” Is your resume bulletproof to withstand its newest line item, “I oversaw a $150 million security breach that made national news and crippled my prior company?” It’s past time to prioritize security within DevOps teams. Jobs for IT security professionals are expected to grow 28% from 2016 to 2026 according to the Bureau of Labor Statistics. It is in no small part due to the evolving needs companies have in warding off mischievous hackers to safeguard their data. In the continually changing landscape of IT, this is not something anyone can afford to be behind the curve on.
Comments on this article are closed.