Common Security Misconfiguration Habits
Learn about common security misconfiguration habits, how hackers leverage these habits, and how to prevent these attacks.
Improving communication between security and dev teams is an important goal for companies that want to stay ahead.
TL;DR:
It’s no secret that security and dev teams have a rocky relationship. Improving communication between security and dev teams has been an ongoing challenge, and is not easy to navigate.
A lot of the time, this happens because each team has a unique set of goals and motivations, but there’s also a cultural divide. Where developers want to go fast and get things to market quickly, security is more risk-aware, wanting to take the necessary steps to make sure the code is as secure as it can be. These traits inform how each team does things, and how they show up to the table when it’s time to collaborate. But the question remains, how can security and dev teams collaborate effectively if they speak different languages?
In this blog post, we’ll be digging a little deeper into the challenges that stand in the way of aligning these teams, and share recommendations for how to get it right.
Security has become more important than ever when it comes to building software products and releasing them to market. With security breaches and ransomware attacks on the rise, it’s no surprise. Despite this, security teams have had a hard time finding a cohesive relationship with the teams responsible for building those products — primarily, developers. So, where are the barriers?
At a high level, the differences are quite easy to identify. Developers want to move quickly, shipping out products and features fast for their customers, and using automation and continuous improvement to do it. This is less of a priority for security. Rather than move fast, security teams are there to ensure that code goes out safely, without introducing any unexpected vulnerabilities to their systems. This contrast is at the source of many of the issues that lie between these teams — especially since they have often worked in siloes to create processes, goals, and performance indicators that align with their worldviews.
This is reflected in the model developers and security professionals typically use to work together. Under the so-called waterfall methodology, engineers built the code and handed it over to security when it was ready for approval. Security would then review the code for any potential vulnerabilities — but wouldn’t always have time to do a thorough review. The time for developers to make fixes was even shorter, and any big security concerns risked slowing down the project altogether.
There has been a concerted effort across tech companies to fix this rift, with the emergence of DevSecOps teams, which embed security into DevOps frameworks, and the notion of shifting security left so that it’s a key consideration throughout the development lifecycle. This push for collaboration is vital if teams want to find an effective balance between speed and security.
Security and developer teams that work well together operate in the spirit of compromise and collaboration. On the one hand, developers take the time to understand security needs so that they can use a security lens as they build code. On the other hand, security professionals have to find a way to mitigate risk in a way that doesn’t impede progress. This balance can lead to several benefits. Improving communication between security and dev teams leaves you with a security culture, where everyone wins.
Customers are always looking for faster software, but a security incident can immediately compromise the relationship they have with a software brand. As such, security is a key component of quality software, and it needs to be a priority for all the teams involved in getting the product out the door.
Crafting a culture of security in the organization helps extend accountability beyond the security team, and gets everyone else on board with making security happen. It also helps to embed security throughout the product development lifecycle, leaving fewer gaps to be identified closer to the launch date. It also goes a long way to facilitating compliance with key security standards such as SOC2.
As Karen Worstell, the former CISO for Microsoft and AT&T Wireless, said in a recent Forbes article, “Developers should be security people in developer clothing.” And security teams have a responsibility to empower developers with the right knowledge. Then, with security embedded at every stage of development — and developers equipped with the knowledge they need to identify and solve security bugs — the products they work on are inherently bound to become more secure.
Teams that are on the same page and working towards the same goal are far more likely to have positive relationships — but this is rarely the case with dev and sec teams. Developers will submit code only to have the security team stonewall them without thinking about the business requirements. Meanwhile, developers will also spend their time figuring out the quickest way to defeat the security team’s tool so that they can still function the way they’re used to.
Improving how these teams see each other and work together can lead to improvements in three key areas:
Improving communication between security and development teams is crucial for fostering a secure culture, enhancing knowledge sharing, and strengthening team relationships. To achieve this, organizations can implement several strategies. Regular meetings with clear agendas and active participation can keep projects on track and facilitate open discussions about challenges. Asking open-ended questions encourages more productive conversations and allows for exploring unconventional ideas. Effective planning, including setting milestones and providing estimations, helps teams communicate progress and identify potential delays. Adopting DevSecOps practices and leveraging automation can help bridge the gap between speed and safety priorities. Additionally, fostering a collaborative culture and focusing on business-risk-based vulnerability management can align both teams toward the common goal of delivering secure, high-quality software.
So, we’ve talked about the benefits of getting your dev and sec teams aligned — but how do you get there? Here are five recommendations (plus a bonus tip) that have helped teams in the past.
We’ve talked about the need for a culture of security. In practice, this means teams have to take on a shared responsibility for this function, as well as a shared understanding of what it means.
For starters, equipping developers with cybersecurity knowledge can go a long way to fostering alignment. Some companies offer security boot camps and learning sessions that developers can partake in for this purpose.
There’s also a conversation to be had around accountability. Developers are accountable for the code they produce and how it functions, and many believe that security should be part of that purview. At the end of the day, the owner of the code is the best positioned to ensure its security. To help action this, we’re seeing the emergence of security champions on the dev team who keep the team accountable for integrating security into product decisions. Where the security team can help here by ensuring that the developers have the tools and any automation they need to write secure code easily and fast.
The security team also has the important role of assessing risk and communicating what developers need to do to mitigate that risk. This shared responsibility can help drive balance between both teams, setting them both up for success as they work towards the same goals.
Help build your developers’ security awareness with our recent blog
Beyond improving the culture and communication between security and dev teams, there’s also a need for tools and data that equip them to work well together. This is where observability comes into play.
Dev and sec teams with robust observability platforms can view system health and security from anywhere. This gives them the ability to access context and analysis in real-time so that they can act quickly and with precision when an issue arises. For example, when a security breach happens, both dev and security teams are alerted with the appropriate data, allowing them to collaborate on a solution. In the event of a system outage, devs can focus on bringing things back online while the security team reinforces policies and covers any potential vulnerabilities enhanced by the outage.
Security standards have become a big part of how we view and treat security, but they only gain real traction once security teams turn them into actionable policies that can be incorporated into workflows. This is where it can be useful to extend the spirit of collaboration and invite developers to the table. This way, they can contribute insights into what will be easy to adopt, where automation could help, and what information might be lacking for the dev team to make the policy fully actionable.
In addition, this approach can make it easier to set expectations around a given security process and identify what team is responsible for each step.
As a bonus, bringing the dev team to the table can also remove the need for security team members to be enforcers, a role that sometimes leads to antagonistic conversations with devs.
This one feels like common sense, but it’s still worth talking about. Security professionals and devs have arrived at their roles through different paths, prioritizing different results, so there’s often a need for sharing these perspectives and experiences.
One way to facilitate communication between security and dev teams is in a social setting with roundtable events where individuals can share their security or development challenges. Casual gatherings, both virtual and in real life, can also help team members see each other as human beings with relatable experiences.
A buddy system, or pair programming, can also help here. This is particularly useful as you make the cultural shift towards embedding security across the board, as it allows for rapid knowledge sharing. It’s also helpful in getting code out the door faster.
Lastly, putting both teams physically near each other — as in on the same floor in the office — is a simple and helpful tactic. Informal communication is important in building understanding, and having your devs and security share the same space and coffee machine can help facilitate that.
Communication between security and dev teams should be transparent and abundant — one team should rarely (if ever) be surprised by the other. Beyond consistent messages, which can be automated where possible, this can also look like hosting sprint planning meetings together, and gathering to review security reports once they’re delivered to come to a consensus on how to move forward.
As a result, you’ll be able to:
There’s a lot to be said about creating policies, structures, and processes that encourage alignment between these two teams. That said, there’s also value in taking a different tack — one that engages people differently.
In some organizations, security teams have opted for gamification. For instance, at a large fintech company in the Bay Area, the security team challenged developers with a series of coding puzzles that related to security. They had a landing page that linked out to each challenge, and if you hovered over the hyperlink you got a breakdown of who had managed to complete it so far.
This accomplished two things. First, it created an atmosphere of fun around the concept of security and showed developers that the security team understands how they think and how they tackle problems. It fostered community and trust. Second, it gave developers a clearer picture of what security is without feeling like they were being lectured.
Effective collaboration between security, dev, and DevOps teams is crucial for balancing speed and security in software development. Breaking down silos and bridging knowledge gaps between these teams minimizes risk and fosters shared responsibility. A shift-left approach, enabled by closer collaboration, allows for earlier and more frequent code testing within the CI/CD pipeline. To encourage collaboration, organizations should consider removing structural barriers and placing security and DevOps within the same organizational structure. Empowering developers to check and remediate their own code for security weaknesses promotes a culture of shared responsibility. Addressing the linguistic barrier between teams through training courses ensures effective communication and mutual understanding. By fostering empathy, changing mindsets, and sharing knowledge, tools, and responsibilities, organizations can create a more secure and efficient development process.
As the tech landscape keeps evolving, the reality is that successful companies are the ones that have built a strong culture of security and have managed to align their security and dev teams. Getting along — and finding ways to collaborate and communicate effectively — is no longer a choice. Organizations that follow the five steps above will be one step closer to finding that balance of communication between security and dev teams, and that will help them solidify their place in the market and the trust of their customers.
Security
Can be easily manipulated without detection if not properly secured.
Digitally signed and can be validated on the server. Manipulation can be detected.
Size
Limited to 4KB.
Can contain much more data, up to 8KB.
Dependency
Often used for session data on the server-side. The server needs to store the session map.
Contains all the necessary information in the token. Doesn’t need to store data on the server.
Storage Location
Browser cookie jar.
Local storage or client-side cookie.
The advantages and disadvantages of testing on staging compared to production. Which one provides more value.
Providing the quality of the biggest names in security without the price tag and complications.
Manual penetration testing
Full time Canadian hackers
Remediation support