For many years, organizations have often approached security as a post-deployment consideration—something to address after a piece of software shipped, or something to address when a breach or other problem occured. Security engineers have made heroic efforts to create safe and secure products in a constantly-shifting, rapidly-evolving business environment.
In recent years, cybersecurity threats have been on the rise, and companies and boards are beginning to prioritize security.In fact, a recent EY Global Information Security Survey found that at 54% of organizations, cybersecurity appears frequently as a topic of discussion for boards. Yet that same survey found that 77% of new cybersecurity spending goes toward “defensive priorities,” rather than forward-thinking improvements.
Often, DevSecOps is positioned in thought leadership circles as the best way forward, but it’s a model that’s proven easier to discuss than to implement. There is not a one-size-fits-all playbook for making DevSecOps a reality, and many businesses struggle to actually put it into practice. In fact, the EY survey mentioned above found that only 36% of organizations report bringing in security during the early planning stages of new initiatives. So it’s worth talking about how to better marry the goals of security and development and bring these teams into alignment in the real world.
Approaching Security with an Engineering Mindset
At Cmd, we work with a lot of organizations who are taking creative approaches to this challenge. Some forward-thinking organizations are combining the CIO and CISO roles at the top. These multi-functional leaders can help bring security and development into alignment. On the field, this can look like security teams learning at least the basics of code, development teams adopting security tools that work with their processes, and both sides coming out of their silos into a place where their shared objective is to deliver secure code—and fast.
In fact, one of our customers says he approaches security from an engineering perspective, bringing the classic mentality of designing, building, and testing to work every day. We find that to be a more practical way to think about bridging the security and development divide than “Let’s do DevSecOps!” which often can’t even get off the ground.
Think about it like this: It’s the difference between a bank building integrated physical security protocols, vs. hiring a few security guards and putting them outside.
This bank puts a few security guards outside. They’re just adding a layer of defense around the business—they don’t change their protocols, processes, or policies. If a bad guy gets past a security guard by acting normally, the inside of the bank is just as vulnerable as it was before the guards were posted at the door.
This bank builds security into the fundamentals of how they do business. Whole elements of operations change—such as how tellers interact with customers, withdraw funds, and more. Security is embedded in every action, activity, and process. The likely result is a much stronger overall security posture.
Bank Two is in much better shape. In other words, often security issues can—and should—be fixed by improving the code itself and taking approaches to educate and collaborate, such as teaching developers to adopt secure coding best practices, working across developer/security silos, and more.
By making security a central aspect of development and IT infrastructure decisions, a company can actually change the way it operates.
Tips For an Integrated Approach to Secure Development
Not everyone is ready to combine development security teams together under a single function, but organizations can still make a lot of progress. Here are three tips from companies who are seeing success integrating these teams:
1. Set Shared Goals and Objectives
Historically, software development—and more broadly, IT—and security have been separate teams with separate objectives. Developers and DevOps teams want to ship things quickly. Meanwhile, security can tolerate a shipping delay if the end-product is more secure.. The result? Two departments that have internal conflict around what they’re trying to achieve—or possibly even mistrust one another.
Getting everyone to share goals, objectives, and vision—in other words, to speak the same language—reduces friction and incentivizes everyone to create a better workflow. If security reports tie back to developer projects, tickets, and other measurable products, then security will not be an afterthought that slows things down. Plus: Everyone can agree that it’s important to produce the best possible product while protecting customer or user data.
These shared objectives can happen on a project level—deadlines, project features, etc.—and at a higher level, such as yearly goals or bonuses that are tied to certain metrics, etc. For example, if an engineer’s bonus is tied to how much code they ship, while a security expert’s bonus is tied to how many breaches occur, they are not operating with the same objective. If both are judged based on safe, timely projects, that’s alignment.
Creating alignment can also be a cultural matter. By participating in each other’s scrum meetings, sharing information, and discussing objectives, developers and security engineers can feel more connected. For example, security teams could share a burn-down chart of issues, so that everyone on the team understands the goal: zero security issues.
2. Provide the Right Training and Tools
Of course, even with shared goals, developers cannot become security experts overnight. Security is a highly specialized field. It’s constantly changing as the business landscape evolves. As you likely know, there is a major shortage of security professionals in the market today, so expecting the few security pros on the team to become coding whizzes overnight is also not reasonable.
Instead, development and security teams need the tools to facilitate collaboration. The right information needs to reach the right people. This can be accomplished when everyone is clear on the proper processes and is using the right tools to communicate and work.
We work with many companies that need greater insight into Linux production environments, but without slowing down work. For example, tools like Slack can be used to facilitate communication between teams and to manage permissions with two-factor authentication (2FA). Even just having 2FA for software development is an example of integrated development and security—controlling permissions and tracking actions is an important way to monitor and prevent credential abuse.
3. Create Ownership and Opportunities to Partner
All too often, security is brought in as an afterthought to developers—which is probably why they can be viewed as slowing things down. Organizations can shift this paradigm by having the same people commit to a single project the whole way through.
For example, if a company is building a new product and the development team is planning sprint cycles, bring in a security team member for every meeting. Give developers and security engineers access to the same workflow tools, like Jira. With shared access, security teams can share the results of tests and flag issues as they come up. . When these events occur, involve everyone as partners to discuss problems—interdisciplinary discussion often yields innovative solutions Combine standup meetings, or attend each other’s meetings when relevant. If, from day one, projects have clear development and security product owners, then there will be greater integration as a natural consequence.
An Integrated Framework is the Future
We all know that security needs to be more than a band-aid deployed after a problem is discovered. Developers and security teams have great power, and in the words of a wise superhero, with great power comes great responsibility. When goals are aligned, training and tools are implemented on both sides, and there is clear ownership across the lifecycle of a product, IT and security teams can become partners rather than being at odds with one another, and that’s a realistic goal for most organizations.
Has your organization combined development and security teams? How do you approach the issue of creating secure code?