Many security practitioners have been frustrated by bad compliance audits, where an auditor wants something that is impossible, or nonsensical, or simply not worth implementing. Or when they accept a security control like the keypad above when it clearly does nothing to prevent anyone from accessing what that keypad was intended to protect.
At Asana, we’ve rejected the false tradeoff between security and compliance. We deeply believe that Asana’s security is significantly improved through our compliance initiatives.
Compliance improves security outcomes
Here’s a simple example: you have a vulnerability management program, and you’ve told your customers that you will fix all high severity vulnerabilities within one week. The reason you’ve done this is that high severity security vulnerabilities are important and you want to get them fixed in a timely manner. You and your team implemented this and then went on to other work.
A few years goes by. Are you still triaging and fixing all of your vulnerabilities on time? What about that one time your vulnerability management solution broke for two weeks and no one noticed? Or that time the remediation task was assigned to someone who was on a long vacation and no one followed up?
A good compliance program will find instances of control failures like these, and then help recommend improvements. This continuous feedback loop is essential for incremental improvements to a security program.
No one would say that well designed controls aren’t crucial for your security program’s success. But many people would say that compliance isn’t crucial. But how do you know if your controls are functioning correctly if you don’t audit them? The answer is: you don’t.
How to avoid checkbox compliance
What about all those compliance controls that don’t actually improve your security posture, like FIPS certified cryptography, or PCI ASV scans, or disabling Bluetooth?
The key is to focus on the spirit, rather than the letter, of the control.
For example, you have a compliance control that’s asking you to audit user access quarterly. What is this control trying to make you do? It’s trying to make sure that only appropriate users have access, and it’s given you a method, one among many, that could work. Instead of implementing that, what if you implemented SCIM to automate the provisioning and deprovisioning of access to that system? Then another control can audit the effectiveness of onboarding and offboarding at your identity provider instead. Another possibility could be to reduce the frequency of your manual audits, saving time.
This becomes more difficult when you do have controls that are overly specific. If the control tells me to implement WPA2 only because you’re worried I’m going to use WEP, I can’t upgrade to WPA3 which is significantly better. A good auditor will understand that WPA3 is preferable to WPA2, and will not issue a finding, even if the letter of the control is using WPA2.
The ROI on security
It’s a common refrain in our industry that security is under-resourced. This can be attributed, at least partially, to an unclear return on investment in security. Big data breaches are rare for an individual company. You can have awful security practices and go years without seeing one, depending on your industry. You can also have good security practices and be hit with a major incident. So, to some leaders, spending on security has little to no effect, and instead you should just invest in your product or business.
Compliance is a way to pay for security improvements, especially at B2B companies. Your customers require SOC 2 compliance, or ISO 27001, or even country-specific compliance standards. You can leverage this to improve your security program. Here’s a simplified way of how it works:
Customer asks for a particular compliance standard, or you believe that implementing it would attract more customers.
The compliance standard asks you to implement a particular control.
You need resources to implement the control properly, according to the spirit of the control. These resources will get you an ROI, which doesn’t normally happen for normal security control implementation.
You implement the controls, and pass the audit.
The customers are happy, the business is happy, and you’ve improved your security program.
Repeat.
Reporting structure
At Asana, the team which handles compliance (named Security Risk and Compliance) reports into Security. We feel that this aligns our incentives in the right way: compliance serves Asana’s overall security needs. Here’s a few reasons why this works for us:
The focus of our compliance initiatives is improving our security program, rather than compliance being the focus in-and-of-itself
We prioritize which compliance standards we will get next by: alignment with our security and business objectives, ease of maintaining compliance, and the level of effort in becoming compliant in the first place
It helps keep Asana Security grounded in what our customers need from our team
There are other reporting structures that can work, and we don’t think this is the only answer by any means. But it has worked effectively for Asana.
Collaboration between security and compliance
Here are some tips to ensure a good collaboration between security and compliance teams:
Align on shared goals. Sometimes security folks demean the work of compliance teams, and that shouldn’t happen, especially when you have shared goals.
Focus on outcomes and the spirit of the control rather than on the specifics of control wording.
Find auditors who care about your security goals and understand how you’re approaching security.
Share knowledge and roadmaps early and often. Compliance comes in many forms. There are certifications, legal requirements, frameworks—all of which have varying degrees of implementation and audit requirements. Engage your security team early and often on how compliance may impact their work.
Special thanks to Monica Khun and the Security Risk and Compliance team.
