Introduction
I’ve seen a few blog posts lately about building corporate security but they are always… well.. so corporate. They are always viewed through the lens of extreme risk but the reality is that most places are not banks or government agencies. The examples given often lock things down to the point where manual work is required for every request which is unrealistic in most public companies. You can (and should) try to achieve your security goals while impacting your employee experience as little as possible in the process.
I figured I’d write a blog from the perspective of startups and smaller companies on their journey to enterprise, starting from scratch. This applies to anyone from the first security hire to IT folks looking at improving their security posture.
Shoutout to Anshuman who wrote a blog about building product security and inspired me to write my own from a corporate security lens.
What is Corporate Security?
Corporate Security is a relatively new term and can be known as Enterprise Security, Internal Security, Zero Trust Security and a whole slew of other things. I’m going to use the term CorpSec in this blog, both because it’s shorter and significantly more metal to say.
If we had to summarize what CorpSec is in one sentence it would be:
A corporate security program involves identifying and securing your devices, networks and software.
This involves a whole host of areas such as device security, IAM, networks, vendor management and obtaining telemetry so that when a breach does happen you have the logs to detect it. Usually, this means working closely with your organization’s HR and IT teams to ensure you’re identifying your assets, building good controls and establishing baselines. The way most people do this in the year 2022 is by following zero trust architecture principles. I won’t go into detail on zero trust here, but an extremely oversimplified explanation would be:
With Zero Trust models you should be able to identify that X user can only access Y service with Z device
Understanding Your Organisation
Most security teams have the same three goals when it comes down to it:
- Reduce Actual Risk - Reduce risk to an acceptable threshold as determined by your orgs risk appetite
- Reduce Perceived Risk - Reducing risk is all well and good but if your customers think your product is not secure then they won’t use it. You need to publicize your security program to do this.
- Customer Acquisition - Security is no longer a cost centre. Enterprise customers will not use cloud products unless they have ISO27001, SOC2 and possibly certifications like HIPAA, FedRAMP and others.
The bit that changes is that every org is different and has different market segments. For example, a startup, a car manufacturer, a hospital and a bank are all going to have wildly different expectations of their security programs. The way this manifests is through different risks, different risk appetites and different compliance requirements.
To address this you need to identify what these mean to senior leadership. This will likely be a mixture of you educating them and learning about the direction they want you to take the program. This step is critical as if you go work for a startup. You don’t want to jump the gun and implement enterprise level security controls too early.
Reduce Actual Risk
Tackling this one is a whole blog on its own so I’ll summarize. You’re going to need to ruthlessly prioritize and start tackling projects that reduce risk. The best way to do this is to create a risk register and rate the risks to your org. Consider the impact, likelihood, t-shirt size the effort and also rate the usability impact on employee experience. Once you have all of this you should verify your list with senior leadership and identify do’s and don’ts. You might identify application allowlisting as a critical project but senior leadership may not want the additional friction that it causes to developers. Without senior leadership buy-in these projects will absolutely fail so be smart and pick your battles.
Reduce Perceived Risk
This one is easy, you need to publicize your security program. At a basic level, it might be writing up some details about your program on your orgs website. At a more detailed level, it might be whitepapers, conference talks and others. The effort you put in here will depend on how much security is a differentiator for your org. Side note here but I really love GitLabs security indicators, they also publish their internal security docs.
Customer Acquisition
This is something I like to call “Compliance Driven Development”. The first step here is to identify customers who are blocked from using your product because of a certain compliance requirement. You can then estimate the lost revenue. A simple mathematical approach would be to calculate if this revenue lost becomes higher than the spend to complete a certification then it’s generally worth doing. Obtain the data from your sales team, dashboard it and show it to senior leadership regularly. Once you get the green light on a certification you’ll need to roadmap it, identify controls and implement.
Initial Assessment
If your coming into a new org or you’ve been promoted internally the first thing you want to do is a risk assessment. You can go full pentest or light touch audit but you need to spend a least a small chunk of time (1-2 weeks minimum) assessing your overall security posture. I recommend looking into device security, IAM, third-party risk management and telemetry as your first areas and we’ll go into more detail on them later.
There are two reasons to do this:
- To assess overall security posture
- To determine the effort involved to change things
Larger, less restrictive companies are going to be more work. It’s easy to roll out security keys to a staff of 200 people in a single office. It’s going to be very difficult to roll out application allowlisting to a company of 10k with no formal program prior to you joining. This information is going to help you with t-shirt sizing projects in the future since you can have the same project in two companies take wildly different amounts of time. You won’t guess entirely correct but it’ll get you in the vicinity of good.
Capabilities and Maturity
Think of security as a delicious cake. You can slice that cake into as many pieces as you want but there are going to be right-sized pieces. As you get larger cakes you probably want to cut more slices. That’s why this section is subjective but I believe these are probably the smallest pieces you want to initially carve out as an individual or a small team. Ultimately you can cut the cake however you want, but trying to eat too much in one go can have consequences.
Once you set up your capabilities you need to mature them and report back to senior leadership. In the early days, this is likely going to be very ad-hoc and based on “gut feelings” but as you mature you should also try to actually measure the controls and improvements you implement with quantitative measurements (How To Measure Anything in Cybersecurity Risk is a great read for this). You can measure your capabilities however you like, there are plenty of models available but the most common tends to be the CMMI.
Below I’ll outline what I believe are the key areas to focus on in the early days and a basic explanation of what they involve. A future blog post will be detailing these in more depth soon.
1. Identity
Identity should be your first priority. It is single-handedly the most important thing to get right on this list. Identity is a wide space and can cover everything in the AAA (authorization, authentication and auditing) space. Functionally what that means is covering everything in your employee’s lifecycle from onboarding, application access, multi-factor authentication, access removal and offboarding. A big focus for you should be rolling out SAML and WebAuthN to eliminate the risk of credential theft which is one of the main ways companies get compromised.
2. Devices
Once you’ve tackled identity, the next priority is devices. You cannot do zero trust and machine identity without having management of your devices. Your goal here is to ensure that only corporate devices can access your most sensitive services. Once you’ve done this you can improve the security posture of your devices to reduce the likelihood of breaches. Commonly you’ll use CIS benchmarking as a starting point but ensure you maintain employee experience and consider tradeoffs with your controls.
3. Third-Party Risk Management (TPRM)
Identity requires you to have an inventory of your applications and ensure they all have SAML both available and set up correctly. In order to do this you need to make sure you have a pathway for new applications and ensure those applications meet the criteria set by your team. If you implement amazing security controls but store your customer’s data in some dodgy SaaS app hosted in a Russian teenager’s basement then it’s all for nothing.
4. Telemetry
In Zero Trust models you assume breach. Assuming breach means being prepared for the inevitable and the best way to be prepared is to have logs available before an incident. If you’re lucky enough to have a detection and response team you can partner with them and do tabletops to work out what logs are valuable. At the very minimum, you’ll want logs from your IDP, device management tools and from communication tools like email. You’ll likely want to look into endpoint detection and response tooling such as Crowdstrike, SentinelOne or open-source tools like osquery.
5. Future Expansion
As the team grows you’ll likely find the need to cut these programs into smaller slices or potentially add more as the business requires. I’ve seen the following be included in CorpSec including Security Awareness, CorpSecDev, and M&A Security. In my current team, we have IT as a part of the Trust team so I manage not only the security side but also endpoint and network engineering teams as well. The key is to stay flexible, don’t silo yourself into these niches. Think about what the business needs to succeed and don’t focus just on securing stuff at the detriment of everything else.
Employee Experience
Almost every change you make is going to impact employee experience and it’s going to suck. I cannot understate this, at some point in your CorpSec career you’ll have to do something you don’t agree with. When you make the change you are likely going to have several disgruntled folks messaging you. These requests can be totally valid. They can also be absolutely horrifying things that should have been stopped years ago.
Any time you go to make a change you should identify usage and measure validity. If only one person is doing something it should be easy to change. If the thing they are doing is designed to be blocked by this control then you’re doing a good job, just help them move to a new workflow.
A closing point on this is that doing every control is often a slider between usability and security. After all, the most secure system is a completely unusable one. This is often represented like this:
The reality, however, is different, you can build out usability and security in your controls but you significantly increase the time component, either through time to build the control or the manual work that is required after it. For example, Yubikeys have high usability and high security but often incur a time penalty in managing purchasing, MFA resets and lost keys compared to factors like SMS and TOTP. A key point to call out here is that the issues don’t scale. If you have to deal with manual issues because of a control, 5% of a 100-person company is easy to deal with but 5% of a 100k-person company less so.
A final reminder is that employee experience is your job. You should consider it with every action you take. When you make an impactful change you should aim to validate if the risks it mitigates is worth the employee experience cost. I recommend having KPIs to measure this or at the very least having occasional projects which increase employee happiness as a balancing measure.
Building Relationships
If you come into an org as the first CorpSec hire then you’re likely going to have to utilize what’s available to you. You should try and make friends with your IT, Procurement and HR folks first as you’re going to need their help a lot in the future. I say this because everything relies on these teams. HR owns the source of truth for your entire company which is the basis for all of your identity controls. IT likely owns all of the device management aspects and likely tools like Okta, Slack and others. Procurement are the gatekeepers of new tools in your company.
These teams are generally supporting teams that are already overloaded and you are going to come in and make a bunch more requests from them. Help them out, get involved in their projects and improve their processes in your first few months. Security isn’t just about take, take, take. Become a resource they can use to help them out, everybody has security questions and most people want to do the right thing. Once you’ve built up this relationship get them involved in your projects and eventually look at building security into their objectives.
Another recommendation is to get involved in company-wide projects. One of the best projects I worked on in my early days working for Atlassian was their internal migration from server to cloud. I got to meet folks from all over the org and it helped me build a good set of relationships I could leverage later on. Many of the teams I met ended up becoming our beta testers for new security controls and tools we were rolling out early.
Closing Notes
Hopefully, this blog post gave you some tools to arm yourself with if you ever need to build a CorpSec program from the ground up. CorpSec is a realm that is improving rapidly right now. WebAuthN is becoming more usable, passwordless is on the horizon and device security is becoming easier to manage. This being said threat actors use the easiest available techniques to own their targets and as we raise the bar so will the attacks. The bar today, frankly, is not high. Ensuring you’re ahead of the pack is a key strategy to avoid a large number of potential threats.
I’ll likely follow up this post with another looking in more depth at capabilities, maturity improvement and what your roadmap should look like in terms of CorpSec priorities.