This month I’ve been thinking a lot about how security engineering teams collaborate effectively with development teams. In my experience, it comes down to these three phases: Awareness, Enablement, and Enforcement. This month I’ll be dedicating an article to each, but as a subscriber to this newsletter, I want to give you a sneak peek. The focus of these articles will be on the critically important area of application security, focused on the roles involved in building software: developers (DevOps), testers, and architects.

Awareness training arms your team to understand how important security is and when to raise their hand for security support. Application security awareness can start with a series of talks, but the best awareness is hands on training. Getting the team to find, fix, or discuss vulnerabilities and threat scenarios is critical in giving them the awareness of when to think about security. The goals of this training isn’t to give the team the ability to find or fix vulnerabilities yet, it is to build a sense of impact and risk. A successful awareness program will provide experiences to draw from that will pop into their heads as they build or test. You want them to be able to recognize when to say “Wait, this has security implications. I’d better reach out to the security team!”

Enablement makes security easier for your team through automation and expert knowledge. Your security team needs to build the trust of the rest of the organization and make improvements to their processes by understanding their pain points and then solving them in ways that are easy to accept and adopt. This may mean instrumenting part of the Dev/Sec/Ops pipeline, building out better libraries, frameworks or defaults, building security unit tests, or to enable the testers to perform security testing alongside the rest of their test suite. The most important part of this phase is to help build software, not slow it down. The security team doesn’t exist to enforce its will on the rest of the company, but to enable them to meet their objectives. I call this “falling into a pit of success”. Make doing the secure thing easier than the insecure one.

Enforcement is the backstop to security. This is defense in depth. Traditionally this is where most security programs start, but to be effective security teams need to win hearts and minds far, far earlier. In a mature model most security activities are performed and issues are found before the security team gets their hands on the software. Enforcement exists to double check procedures have been followed and to catch issues that slip through the cracks. This is also often where audit, compliance, regulatory checks can be performed.

Sometimes security teams will feel as if they are the last bastion fighting against the dev team who is ready to deploy insecure software to get features out. However, we are all in the business of building secure software and building trust with our customers. Every person at your company is trying to balance the many facets to quality software as best they can. Understanding how security fits into your overall process and how to build secure software without slowing development and deployment down is critical to the success of any company. A cooperative model will always be more effective than an adversarial one.

More Security Headlines

This technology uses AI to drastically reduce the data sent for video conferencing. The result is the output is a virtual avatar that looks like the person’s face. This is great for bandwidth, but I wonder if we loose some nuance in translation. If we know the receiver is looking at a video of our face and every glance or micro-expression will be sent, we may act differently than if we know they’re receiving an approximation of what an AI thinks is happening. Maybe we could have a little fun with this and all swap faces for the next team standup? NVIDIA Uses AI to Slash Bandwidth on Video Calls

This article is great. I love the saying “if you don’t look back at your earlier work and cringe a bit, you are not growing” Paul Graham makes the case that we need to try new things knowing that we may sometimes fail, but it’s the trying that will lead you to build something great eventually. http://paulgraham.com/early.html

I love that GitHub has just enabled code scanning to all users! This is a great example of the security enablement that I recommended above. The fact that they’re making this feature available to everybody no matter their payment plan is a huge step forward for code security. GitHub rolls out new Code Scanning security feature to all users | ZDNet

It’s hard to imagine building a modern application without an API. They’re the core of every new web, mobile, or desktop app today, they’re what connect connected devices. They often lack security, though, because they’re hidden far behind the application’s UI. Cloudflare has rolled out API Shield to help combat the vulnerabilities at the network layer. This is another example of security enablement. See a theme? Introducing API Shield

Another example of hackers moving from the simple ransomware to extortion. Many of the recommendations for good Disaster Recovery strategy to protect ransomware is still good practice, but far from sufficient. How hackers extorted $1.14m from University of California, San Francisco - BBC News

Activists are using facial recognition to identify police who have covered their badges during riot control and other altercations. It’s fascinating to think about how easy this technology is to use. Howell, the subject of this article, has been working with AI image recognition for years, but there are many resources to make this possible for anybody to pick up. Activists Turn Facial Recognition Tools Against the Police - The New York Times

After recently moving to Montana, seeing this article was quite a treat! The world has changed during COVID, I think there will be a large number of things that never go back. I hope virtual first companies and to-go cocktails are here to stay. ‘Zoom towns’ are exploding in the West

Researchers do the previously thought impossible. They destroy a massive, 27-ton generator by injecting new instructions into the system’s software. Causing permanent physical damage through software vulnerabilities is an eye opening new threat. How 30 Lines of Code Blew Up a 27-Ton Generator | WIRED

Every piece of software you add to your enterprise is a possible attack vector for a malicious actor. Even if that is security software. Take care to install what is needed and monitor for bad actors. FBI: Hackers stole government source code via SonarQube instances

Please note: “>