(Re)Introduce application security to your team

by Prabhu Subramanian on June 6, 2020

This blog was originally published at blog.shiftleft.io

Imagine you are a Development Manager or a DevSecOps leader in your organization thinking about AppSec.

Having an open conversation about application security with your team is like having those difficult conversations with your teenagers. You know you’re trying to do the RIGHT thing, but the team won’t LISTEN. You might try starting the topic by Injecting OWASP top 10 casually but before you could reach Broken Authentication, you would have a Broken Attention from your team. The team would be quite Sensitive to their deliverables so any attempt from External Entities to Control and influence Security Configuration could inadvertently make them get Cross and Insecure. In fact, we might make them more Vulnerable (un)Knowingly even affecting the ability to Audit and Monitor the delivery and productivity. (I tried injecting OWASP top 10 here!)

You can have all the literature and white papers from your security vendor. You might have seen the demos that talk about analyzing a million lines of code before you could get to that coffee machine or performing analysis on a commodity hardware. You might even have the single universal formula for DevSecOps. But none of these are going to help with that difficult conversation.

Alternatively, you might think that you can ignore this chat and let the security product speak for itself. This is true to a certain extent if the product was built specifically for the modern DevOps workflows. Unfortunately, most security products that you might be aware of do not fit this description. There’s this 2×2 rectangle Gardeners love top-right reserved for supposedly leaders of our trade. One of these leaders has a product that costs like a whole Ferrari every year. This leader after extensive research found that their clients barely use the product at all. In fact, the usage was less than 4 times a year across the customer base globally.

Sponsorships Available

If you are looking for areas to cut your costs and outgoing ones, how about ditching or replacing security tools that no one is using?

In this blog, I discuss some ways leaders and managers might have a constructive conversation about application and cyber security with their team.

Think security as engineering

Times are changing quite fast. When we started our career, we all had those big cubicles and offices with dedicated landline extensions (What is Slack?). Information Security was mostly controls imposed by the governance people based on the likes ISO, CIS, NIST and FISMA. Remember those beautiful spreadsheets and ISMS tools that allowed us to wonderfully map the 14 CIS controls with ISO 27001 that we could then fire off to those auditors before heading to the beach? Phew, good old glorious days.

But things are changing. Those nice spreadsheets can no longer keep our organization and customers secure. A control such as “Perform port scanning periodically” is irrelevant if your DevOps team use a s3 bucket that is public with the admin access key available on GitHub.

Security is engineering. You should speak engineering not governance if you want the dev teams to listen and adopt application security. Ask questions such as:

What is the CI/CD tool you are using? What is the tool you would love to use?

What is your favorite IDE?

How do you monitor your production application for errors and performance?

Answers to most of these questions might be well-known in advance, after all, Jenkins and Azure Pipelines cover 80% of the enterprises. But this would be confirmation that the best place to introduce security is CI/CD and IDE and not spreadsheets and outlook. And if the CI/CD tool used is quite slow then introducing security scanning will only worsen it. So, think about introducing security scanning that doesn’t impact the speed perhaps a cloud-based scanning product that doesn’t use your source code?

If the teams do monitor their application in production, then guide them to understanding traffic from bots and port scanners and spotting unexpected authentication and IAM errors.

Move away from gatekeepers model

Back to the good old days when we all went to this corporate HQ for work. You enter the lobby and look for your badge in your leather bag.

“Please wear your badge at all times so that we can see them,” said the security person with a stern look.

“Absolutely, sure thing,” you smiled as you swiped the badge to open the barrier.

Security gatekeepers model is irrelevant

This gatekeeper model for security (checking during entry or exit with occasional audits) worked well for applications and services that got deployed to a secured locked-down dedicated data centers.

Nowadays, there is no HQ. You don’t need a badge while working from home or from a coffee shop and join your team on Zoom and Slack every day. Everything is in the cloud or in multiple clouds and PaaS. Teams own the keys to their cloud castle and decide how they use their keys. It is simply not possible to have a handful of gatekeepers who can pen-test externally and claim things to be secure. No wonder 80% of the organizations suffered a breach in the last 18 months and security misconfiguration and lack of visibility are the top security concerns.

Avoid fights

If a dev team doesn’t use a security tool because it requires them to change their workflow, it is the tool’s fault.

Fighting with the team and using the organizational hierarchy or title to enforce change will not help.

It is also possible that your security vendor is not that open and transparent with you after all. For example, statically analyzing a dynamic language like JavaScript requires a fundamental break-through backed by research. It is simply not possible to detect vulnerabilities in custom code and frameworks such as React by simply using regex or statistical model such as variance analysis. So, if the dev team argues that the reason, they don’t use security tools for their SPA application is because none of the household brands are good, they are right!

Check if the security vendor is willing to address the concern or if the security tool offers flexibility to extend and customize the policies and its rules. In certain cases, the teams might decide to create their policies and rules from scratch when given a proper code analysis platform.

Encourage a process

If you want your child to study and finish homework on time, you can’t shout or scream at them once and expect them to change their behavior. Such a self-fulfilling prophecy should always be avoided. Instead, try to encourage a systematic process for embedding security. Perhaps, start with including security as part of a pull request process and mandating checks from security tools in addition to reviews from colleagues.

Faster PR process when tools work together with people

As a next step, include such security checks as a release gate for deployment and software delivery. Invest or implement a Software Delivery Model that includes security tests in addition to functional and performance sign-off as a condition for deployment. Feel free to customize the policies depending on the kind of deployment environment — a delivery to a test or integration environment need not satisfy all the criteria that are mandated for a live environment.

Closing thoughts

At ShiftLeft Inc, we are quite used to helping clients have these difficult conversations and implement AppSec and DevSecOps tooling and processes that is suitable for their needs. To discuss your specific needs, just get in touch with us or join one of our office hours

(Re)Introduce application security to your team was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.