Automating Security Culture 🌺
Why is automation important for building a security culture?
You’ll find automation in every successful project that builds a security culture. A company’s culture is made up of the many tasks and relationships that connect different teams. A security culture is how teams enact these practices from a security perspective. Automation is useful to improve collaboration, accountability, and growth in a company’s security culture.
In the security realm, it is a huge advantage to have requests to collaborate between teams met with resources that are as self-service as possible to reduce friction. Through these cross-functional efforts between teams, we can drive security practices in all phases of a product.
Automation can provide visibility which creates accountability. Through automation, the repetitive bits of work is accounted for, now an engineer can break out of doing tedious work, instead focus efforts towards optimizing this automation for a larger set of use cases. This mindset help consider diverse use cases and helps deliver security to a larger audience.
In a modern company, growth is a very common problem. Automation can help address this problem at scale. After a company reaches a large enough size, security practices need to become universal and delivered through the system. We realized that in order to successfully deliver on a practice as a security team, we must scale the practice across our organisation as well. We use automation such as such as our Jira Service Desk ticketing system to communicate the expectations of a practice to a wider audience. This also helps gather metrics and pain points across a larger group of people, and improves our process internally.
Developing a knowledge base - Quantitatively assessing research and knowledge sharing
We have a space for a knowledge base, therefore; the big question is how do we ensure the usefulness of topics in the knowledge base? As security engineers the primary reason we would want to build a knowledge base is to understand trends and patterns in vulnerabilities we’re seeing across all Atlassian products. We can classify each vulnerability into classes according to the industry standard OWASP. In our first iteration we chose Information Disclosure as the class to work with, simply by measuring volume of issues in our vulnerability funnel, that is our “Security Jira”. We had interns coming in to pick up a class and demo their findings as well! However, we needed somebody to keep doing this task repeatedly over multiple quarters to show results over time, and keep documentation up to date with changing trends for a vulnerability class across all products. Valuable experience as it is, this project was difficult to scale and operationalize over time
A knowledge base is important to security culture because it informs how developers will code securely and use secure practices
If someone was looking for an article, we want to optimize the chances of them looking for it in the knowledge base. Some key features of a living knowledge base:
-
Must have credibility in having the most up-to-date articles
-
Useful succinct guides to help carry out a security practice
-
Encourage and incentivize contributions from outside the security org to have product specific mitigation, vulnerability and remediation information.
Our knowledge base resides in Confluence and we leveraged the APIs provided by Confluence to grab metadata on each page of the knowledge base directory. We used CQL to filter which directory in our space we’d like to process for information. Using this subset of pages, we extracted metadata, for example - page_id, last_updated , total_number_of_views, total_number_of_unique_viewers, contributors, and page_title. We also used Bitbucket pipelines to set up a scheduled job daily to update this data table in the Atlassian data lake.
Setting up this automation helped answer quantitatively which parts of the knowledge base need to be improved upon. In our use case the main use case was serving the user with the most recent information and to keep the knowledge base a living entity. Our automation populates a dashboard with out-dated pages under some metrics and thresholds we set up internally.
Fostering security champions culture - Enabling developers with automation
The security champions program has been maintained over many years. Each onboarding process has been a different experience for a security champion. To gain more engagement with the product teams, we have repeatedly mentioned that it is a volunteer program. We don’t enforce strict agile or scrum practices for champions. Each champion must decide for themselves the level of participation they would like to have with the security team. This relationship can be maintained through incidents we might have or we can even leverage this relationship to scale our practices. In order to programmatically have a rough count of active champions we must have a set of patterns or behaviors we’d like to see to tag them as active champions and keep them engaged.
We need collaborations with the product teams to effectively drive security into the product. Security champions are the connectors of information between the product team and the centralized security team.
We have champions who have successfully been onboarded, but no longer want to participate as much. This can be related to growth or scope changes in their existing role. On the other hand we have an enthusiastic bunch who are always help out.
To maintain their active status over time, we’ve written a query that filters active champions on the following criteria
-
They onboarded as a Security Champ in the last 6 months, OR
-
They passed a Secure Code Warrior assessment which is our training platform in the last 3 months, OR
-
They completed a VULN ticket AKA vulnerability ticket in the last 3 months.
-
We also need to make sure that the champion is not on extended leave
Atlassian offers other avenues for participation, we gather data and quantify participation on this criteria.
One-stop shop for requests - How to ask help, from a human
As a centralized team, the Trust team have a service desk where product teams or internal teams can raise requests with us. We have multiple unique operations within our team, we have a request type for each one.
We leverage this product day to day internally between teams to capture requests. Sometimes our Jira Service Desk already has a category for the request that needs to be raised. Then it’s simple! There’s a dedicated sub-team in the security organisation that would only look at this request type and triage them on a weekly basis. But what if your request doesn’t fall into any of the default categories we already have? Who is responsible on the security team to triage or scope requests like these..
These requests come under a catch all queue in our Jira Service Desk. The issues in this queue are difficult to automate as there is no set pattern among them. Hence, these requests need to be manually reviewed.
Not everything can be automated, so we have a catch all queue.
This creates a reasonable amount of work, but it is important - at the end of the day, product teams are our customers and they need to feel supported. While there is a lot of noise in this queue, there is also a good signal from developers which leads to important vulnerability investigations
Conclusion - Automation is essential for a healthy culture
I would highly encourage to use automation to grow security culture by breaking down boundaries and connecting people. These categories mentioned - research and knowledge sharing, Atlassian security champions program and having an internal catch all requests queue are all interesting and important topics to explore for a company. The challenge resides in scaling and accounting of ad-hoc events. At Atlassian, we were able to automate a good number of tasks and make our relationships with the product team healthier over time.
Here at Atlassian, we continue to use our in-house products to accomplish repetitive tasks and measure our success by having good metrics around them. These automations can’t run by themselves and they need to be checked upon from time to time. Having a group of people responsible for growing and scaling the outputs of the automation will mature our set of capabilities and in-turn enhance our security culture.
Security Culture == Accountability
Nisha is security engineer at Atlassian. This post is a excerpt of a presentation she did at Loco Moco Product Security Conference 2022 held in Honolulu, HI. Connect with her on :linkedin: Nishchala Tangirala.
Was this helpful?
Thanks!
Nishchala Tangirala
1 comment