Dept. of Know Live: Omar on building secure apps the easy way | Fastly

When we think about modern applications, characteristics like dynamic, personalized, and highly performant probably come to mind. Making them secure might be a goal, but too often it’s viewed as an afterthought or a roadblock. 

There’s a better way. Like JupiterOne CISO and Head of Research Sounil Yu discussed in the second installment of The Dept. of Know Live!, security can actually be an enabler of innovation. Last week, I joined the series to chat with Kelly Shortridge and Bea Hughes about why building modern applications means building secure ones, and how we can successfully make security a more inherent part of the development process by making the safe way the easy way. 

Watch the conversation here, and catch up on a few of my top takeaways below.     

1. Consider your end user and security UX before implementing new tools or solutions

We have to remember that security is ultimately about meeting people where they’re at. Engineers and developers need to understand that the security team is on their side, and that all have the goal of creating the most robust applications possible, with security being an inherent part of that equation. Being clear about that incentivizes engineering to be just as invested in security as the security team is. It’s important to keep in mind that engineering is your target audience, not the security team. Security tooling needs to be as consumable as possible by engineering to reduce friction and ensure that it will actually be understood and used. 

Security teams run into issues when they implement security tools and programs without considering their end user, thinking about security UX, or performing user research to understand how developer workflows will be impacted. There’s a tendency to jump to saying no instead of proposing an alternative or understanding the context and use cases of a project. For example, if you’re deploying a WAF, you need to work with the engineers who developed the web app so they understand how the WAF might change the way HTTP errors are handled. Without that context, they could suddenly have issues with their error monitoring or see errors that they don’t know how to diagnose. Collaborating closely with developers to understand how a security tool impacts their work can help the security team make better decisions about their security programs.   

2. Understand the distinction between safe vs. secure

We don’t often talk about the distinction between safe vs. secure, but understanding the difference is important to the success of your security programs. You can have software that’s secure in the sense that it does the right thing if you know how to make it do the right thing, but it’s only “safe” if it makes the decisions for you in a way that makes it very difficult to do the wrong thing and put yourself at risk. If a security tool identifies a vulnerability, but if the developer’s first instinct is to turn it off because it’s too burdensome, then it’s futile. 

I liken security engineering to building IKEA furniture. An IKEA manual doesn’t have any words in it, but someone following the diagram can safely and easily build a functioning chair. Similarly, security teams should learn to provide guidance in an easily digestible format and find ways to make the secure way the easy way. For example, static analysis tools can block a build when they detect vulnerabilities, but they are often deeply technical and difficult to understand. When I’ve built these tools, I try to minimize the number of situations in which someone might see an output and have to reach out to me directly by providing as much context as possible, giving examples, and linking out to documentation so that developers don’t simply remove them from their CI/CD process.   

3. Negotiation is essential to meeting security goals

Security and development teams will both have their own goals, requiring some negotiation to find a happy medium. For example, one common security requirement is ensuring that users can’t access data in bulk, but application developers might want to complete a project without having time to build scraping mitigations or prioritize rate limiting or access controls. Instead, security engineers can use a WAF to set blockers and rate limits, then communicate to product teams that those capabilities are at the WAF level, but should ideally be built at the application level post-production. That way, security is there to support, not block, the release of products.  

To sum it up 

Security should be inherent to building modern applications, but too often it’s not because of miscommunication between security and development. To get on the same page and create the most robust applications possible, security teams need to prioritize effective collaboration with development teams, and have more curiosity about the “why” of it all. That’s how we get to a place where an application is not considered strong unless security has been successfully baked in. 

Watch our full conversation on demand, and tune in later this week on March 24 at noon PDT when Ellen Körbes, Senior Product Line Manager at VMware Tanzu Kubernetes, joins The Dept. of Know Live! to chat about how security falls short of developer expectations.