SupportLogic Security-First Architecture
Security is often treated as a checkbox, but it’s the foundation of trust. This session will challenge your complacency by exploring SupportLogic’s Security First Architecture. You’ll learn why security should be integral to every layer of your support operations, and what SupportLogic has built to align with that expectation.
You Might Also Like
Folks, security is so important at SupportLogic.
We have Tyler here.
We have an absolute expert here to talk all about our security and our data
pipeline and
everything that we do to keep our customer data secure, but also flexible.
Tyler, if your mic is on.
If it sounds like it is, check, check, check.
Is it coming through?
I like it's a little better.
Sound check, right?
Check, check.
Close enough.
All right.
Well, I'm going to stand here and talk about it.
So good afternoon, everyone.
My name is Tyler Pinkard.
I'm going to be talking about our security architecture here at SupportLogic.
I'm making up for a little lost time, but if you have questions, raise your
hand.
I'd love to hear them.
So overview, stuff we're going to talk about.
You guys can read the slide.
I don't need to labor it.
Onto it.
Me, I'm your speaker.
Hello, I'm Head of Security.
I'm the data privacy officer here.
The word of this is a bill.com for four and a half years where I built their
DevSecOps
practice and was a founding engineer to a blockchain start before then, as was
cool
at the time.
Here in the valley, I'm on the board of the Information Systems Security
Association.
I'm active in the community and I work hard to keep your data safe.
All right.
So perimeter security.
It's out.
Don't do that.
All right.
So let's start off.
Talk about what security is.
All right.
Security is not one thing.
It's a combination of systems that come together to deliver a few things.
We want to maintain assurance of our environments as we're running the code
that manages your
data.
We got to protect that data.
Keep it out of bad guys' hands.
Keep it off the internet.
And make sure we maintain compliant.
That was actually a former CISO of Levi's that told me this.
It's like, what are you doing?
Security.
It's like, oh, you keep the system safe.
Wrong.
All right.
You generate systems that are able to generate the evidence that you provide to
auditors to
give them proof you are keeping everything safe as you say you are.
Now, we got some cool names on the board.
Everybody in this room included, but these ones were asked by my boss, Krishna,
right?
These serious security companies entrust us with our data, right?
And they are obviously large targets of attack.
And it's important that we maintain assurance of it.
But these guys trust us, so you should too.
All right.
So we got some certifications.
All right.
Sock 2.
I'm actually in the midst of my sock 2 audit right now.
I believe our sock 2 auditors will be joining us this afternoon because their
office is around
the corner.
ISO 27001, I just finished our surveillance audit a month before last.
GDPR, HIPAA and CCPA, right?
Mostly on the breach notification side.
We do regular internal and external security audits.
I'm lining up our pen testers for my next round of sock.
Looking to get that engagement underway.
Next month, shocks were already in October, right?
But not only are we doing internal external pen tests, we invite our customers
to try out
your environment.
Try and beat it up.
Let me know.
All right.
There's no perfect approach.
But you can use a bunch of different pieces to build a robust security program.
Let me see if I can make this a little bit bigger on my screen.
There we go.
Okay.
So we're not just keeping bad guys out, but we got to make sure our workforce
and the
infrastructure is secure.
And that's a multifaceted problem.
That's not just people.
It's not just your execution environment.
And for the nerds in here, that's prod, right?
Development support systems, that includes our CI/CD.
That's a gnarly way to get popped.
They bust into your CI/CD and now you're shipping malware, right?
Endpoints, that includes mobile devices, laptops, right?
That's all in scope of our security.
And the communication systems are timed together.
And that's email, Slack, Zoom, GCP, Workspace.
I can keep going.
Now, while I'm going to be talking about some of the things I do for security
and support
logic, this is not a comprehensive presentation.
I am not giving you a blueprint to attack my systems.
All right.
What I want to do is put your mind at ease.
There's other stuff too, right?
We're just going to get you excited.
But I want you guys to understand how we approach this and how seriously we
take the security
of your data within our firm.
All right.
And so this is 2024.
Perimeter security is no longer sufficient, right?
Your firewall administrators and the network guys, oh, we'll just keep them out
We don't have to worry about anything.
It's not really going to cut it anymore.
The wall castle is dead.
There are holes in all of your walls, right?
The old way.
Strong walls.
You've got a mode on the outside.
You know, big draw gate.
You can crawl up a porculus.
You can drop down on people that try and charge you gates.
All right.
But once you're inside the walls, it's an open field.
Help yourself, right?
All you can eat buffet.
It's expensive to attack.
But conversely, you've got bad guys on the inside.
It's really hard to detect and prevent them from doing gnarly stuff.
They're not supposed to be doing.
So what are we doing instead?
Well, attacks can't come from anywhere inside the wall, outside the wall.
What if I was an attacker, right?
We use a variety of threat models to define how we build the defenses inside
our building.
So baseline is a zero trust approach, defense and death.
This has become hip these days.
NSA published a model to zero trust.
Security, I believe 2015, and then that's rolled out across.
This is what Google uses inside, right?
It can come from anywhere.
I mentioned that.
Off and encryption attacks.
Also everywhere.
And this is even more expensive to attack because it's not just get inside the
wall
and you're free.
Once you get inside the wall, you're still getting questioned at every
interaction.
Hey, how do we know you're supposed to be here?
Oh, you've got the right credentials.
Great.
Let's make sure that's going through an encrypted tunnel.
And the advantage here is that this reduces the risk of inside threats.
All right.
So starting from the top, the VPC architecture, right?
Those of you guys that might do some cloud engineering on the side, be reh
ashing.
But again, let me know if you have questions.
So we maintain a model of single tenancy for our customer environments.
Salesforce data is not being co-executed with CrowdStrike data, which is not
being co-executed
with NTT.
This means separate networks for every customer environment.
Separate compute.
Separate storage.
And this is uncommon in most SaaS applications.
And the reason is because it's expensive.
That means we run duplicate infrastructure for all of our folks.
Now why it's expensive?
Why would we do that?
Right?
Well, we understand the importance of the data we're processing and we know how
important
it is to keep it secure.
It's literal threat to our enterprise.
And that's why we take it as seriously as we do.
So there are some cool things about running a single tenancy from the
administration side,
right?
We get data isolation and security.
All of your data lives separately, right?
This reduces my risk of data breach, right?
Because everybody's running in separate buckets and it's unlikely you'll get
them all.
And this is important for industries that have strict compliance requirements.
All right?
We are-- allows for greater customization and flexibility, right?
Single tenancy?
Salesforce, you'd imagine.
Lots of tickets.
It probably needs some pretty beefy hardware.
That's not universally true for all of my customers, right?
And this allows us to use targeted infrastructure sizing in order to meet your
specific performance
requirements, all right?
Changes and enhancements can be made to one environment without impacting any
of the other
customer environments.
The performance optimization side, right?
That's the other side of that coin.
So since we've got every tenant on their own copy of the infrastructure, right?
Performance issues that might impact one customer are isolated from the other
ones, right?
And this allows us to be very specific with how we turn the dials and adjust
the VM sizing
or the database sizing in order to support your operations.
So these are compliance, right?
We've got some of my folks, right?
They have very specific GDPR concerns.
And because we're single tenancy, I can run a copy of their infrastructure in a
European
data center, typically Frankfurt, right?
Because I've got very strong reasons.
But we can set up specific infrastructure that is tailored to individual tenant
needs
without impacting the overall application.
You're told that updates and changes.
Again, we do it on a customer by customer basis.
And this means that bugs that may impact one customer are isolated to that
environment.
And we can roll out updated software to fix that issue without bugging anybody
else.
And it has support, right?
Support can go straight into your instance.
Makes it very easy to reproduce those problems and can lead to quicker
resolutions on our
side as we support your use of our application in your organization.
Right?
Resource allocation.
I touched on this before.
Dedicated resource.
And because of that, this can lead to greater performance in high load
situations.
And in the specific where you've got one customer facing high loads, that's not
going to impact
my other ones.
And then me on my cloud operations side, easier backup and disaster recovery.
This is one that we exercise every six months and I'll be moving to quarterly
because it's
like lifting weights.
You want to get stronger.
You lift bigger weights.
Right?
We practice this a lot because this is how we make sure that if something goes
wrong,
we can get you back up and running as quickly as possible.
All right.
So let's touch on our data security.
And I'm talking fast because I'm making up a little bit last time.
But please feel free to raise your hands if you have any questions while I'm
stepping
through this.
Welcome to the opportunity.
So we're going to keep your data safe.
And we use ELT to pull the data out of your side.
Most folks are using 5-tran.
We've got some options that I'll touch on and how we can do that.
Data's pulled over SSL using REST APIs.
All right.
We reach in to your CRM whether that's Salesforce, Zendesk.
There's some others I can't pull out.
Jira.
All right.
You give us the authentication token.
You skip, scope the authentication token and we only have the data that you
choose to share
with us.
You don't have to share those credentials directly with us, especially if you
're using
the 5-tran option.
You go in and set up that connection.
And then I never hold them at all.
And that means I never have the opportunity where I can lose them.
And then access is maintained to the BPC using self-service.
All right.
Let's talk through our data flow.
And we'll start it from your perspective down at the bottom.
CRM.
ETL.
Or ELT in this case?
Yes.
Well, it's just whether you decide whether you're going to extract load and
transform or
you do the extract, transform and load.
I've seen them use both.
So excuse the slip.
But pulls that out, shoots it into Cloud SQL on our side.
And that's we have some scope like option.
I'll get into it in a bit.
But we started with a single tenancy Postgres database.
So everybody's got their own Postgres database.
All right.
Pulled into the back end.
We do some neat AI models.
Generate some signals.
That goes up to push us out to the user interface, which you can reach into,
just like you log
into your bank, HTTPS, JAPD56, or I say encryption.
And then from my side on the administration, we have 2FA mandated on any SSH
connection.
And I'll talk about how we do the authorization into that from the DevOps and
operational
side.
But these are the data that we're going to actually pull out of your CRM.
This is all we need in order to drive those models.
It's got Alex and her team build.
And these will be the case details.
No, it's comments, discussions.
Go ahead, sir.
[INAUDIBLE]
Yes, we absolutely have.
We're building it now.
I'm going to leave that to the product.
But thank you very much.
That's a great question.
I am pretty sure we've got that coming up in talks.
Yes.
And I see the lady speaking after me nodding.
So we'll put that in the parking lot.
But we will have that answer to you in less than an hour.
Case requestor details, agent details, and then product usage message metrics.
That's just how we track how using our system so we can make sure we're
building you good
systems.
All right.
So another view of our data pipeline.
You got your CRM.
We extract it from your sign.
We load it into ours.
And that goes into the CRM.eb.
It's like a post-press.
It's what lives inside the support logic that you can see,
syntenancy, so it's just your stuff.
All right.
What do we say?
Check the credentials.
Read the permissions.
Transform the schema.
Make the field requests.
And then the other option, you can come in to look at it on the UI.
Or we can push that data straight back out to your CRM.
And we have customers that use this in both ways.
Some one, some the other, and some together.
So how can we get that data out of your system?
Well, I touched on 5-tramp before.
That's our cloud ETL.
All right.
That's either in the standard or a versus SSH.
If you don't like inbound connections,
you can push it out through a versus SSH tunnel.
Data replication via Snowflake.
This is turning into my favorite way, right?
Because now we don't have to vacuum it out.
We don't have to pay five current controls.
If you've already got all this data inside your Snowflake instance,
you can share it directly with us.
And then that saves.
It makes our models faster and it's cheaper to operate.
So if you do that, you're interested in that.
Please talk to us.
I would love to help you go ahead, sir.
Are there plans to make it more real-time?
What kind of is the data movement?
[INAUDIBLE]
Well, and that's the thing about 5-tramp, right?
The closest we can do on a sync is 5 minutes, right?
And so that's what sets the cadence on how often
we update that data.
Now, if you're pushing that into Snowflake, right?
And it's how well are you feeding that data that
composes the data lake in your Snowflake?
If that's live data, then we already
have live data in our system, right?
It's just 5-tramp starts to break down
because we can't get them to turn up that sync frequency more
than 5.
That's what sets that limit.
However, we've got other ones where we can do on-prem ELT.
If you wanted to, you could host your own.
So it's not 5-tramp.
We do have a customer that does this today.
And we can push that every 30 seconds or 5 seconds.
That's where we start getting into the performance cost trade
offs.
But absolutely, there are ways to do it.
It's just a more of a custom config
than going with what we got in our out-of-box solution.
And then on the data replication side on Snowflake,
we can use a tool called ArchyOn, which
was bought by one of our customers,
where we can read in from any discrete data location,
push it into Snowflake, and then replicate it in that fashion.
And then the on-prem ETL, where you hosted chunk code
and push it to us, either a hosted version of 5-tramp,
which still has the 5-tramp limitations,
or you can use the air byte.
And so that's sync to 5 seconds if you're so clamped.
All right?
So data restriction.
So how do you make sure you're not sending us data
you don't want us to have?
Because again, we have very tightly scoped data stuff
that we need in order to drive our models.
First one, you can change it in the application itself.
Like we can, at the front end, adjust the levers.
We still have all that data on our back end,
but this allows us to do this filtering in real time.
Two, all right?
You can scope it on the permissions
that we use to reach inside your CRM
so that we only have access when we have visibility
of that data you want.
Three, filter it before it even gets to your data lake.
Then you lose possibility of doing some de-correlations
on your side that maybe we wouldn't necessarily be doing.
And then four, you can filter it inside the ELT itself.
But again, we understand the sensitivity of the data
that we are processing.
We are not trying to steal your data.
We only want to have enough to be able to drive our models
and give you the signals that you've passed for.
So data protection.
We do protect our data.
We do encrypt the data.
Data in flight.
Data at rest.
Encrypted at every point.
The one I'll point out here, because this
gets the security guys excited, VPC instance,
because we have separate keys for every customer.
We are fully FIPs.
140-2 come flying.
BYOK, this is something I built, or my team
built in the last month.
And we are--
I don't want to name the specific customer,
but it's one of the security conscious customers you saw
on my slide before.
They had a requirement.
They wanted to host their own key.
All right?
In the way we did this, you guys create your KMS key in GCP.
You share it to us through IAM permissions.
We assume that role.
We can read your key, and now we use it transparently.
Something happens.
They don't like it.
They change their key.
Now they've just blocked access to us accessing their data.
And that's OK.
Right?
It's your data.
We want to process it in a way that makes you happy.
But I'm proud of this because it's
neat to be able to add new features without having
to change our product.
That's just coming at it from my side on the intro.
Data classification matrix.
When I point out here, ticketing data--
We classify that as confidential.
I mean, that's only yours.
And our sensitive is internal.
That stuff that we just keep inside,
although some of our customers do want to get that out.
Again, we want to make sure you're
comfortable with us processing your data.
Code to cloud.
Let's talk about security posture.
All right?
So we've got our requirements to find a JIRA.
Those commits are linked to Git.
I'm going to go quickly through this because this is pretty
generally accepted cloud security information.
We do mandatory code review on all check-ins,
at least two party.
So it's nobody pushing code and running it in prod.
It has to go through review.
Static and dynamic code testing, as well as SCAA,
is integrated in my CI/CD pipeline.
So it's not someone remembering to run these tools.
They happen automatically.
If we move outside thresholds of acceptance,
then that risk has to be assumed by the folks deploying
the code.
And then we have a formal process for that.
I'm going to give a shout out to QuietAI, who is one of our
customers.
And we use their service.
I like buying my customers' products.
Great, sweet.
I don't know if you guys need static or dynamic analysis,
but I would point you to them.
Anything that comes up is reviewed as part of the QA
process and build acceptance.
That's what I touched on before.
And we have regular developer training, both in security
and best practices domain.
All right.
We call this the DevOps infinity circle.
But the thing is, it's never done.
We build it.
We deploy it.
We monitor it.
We integrate.
And we report.
And we stay on the cycle forever.
It's my team that's responsible for keeping your
systems alive and running.
We have a 24/7.
NOCSOC level one that spins up to a level two alert system
depending on what's going on.
All right, let's talk about some secure deployment practices
and harden environments.
Infrastructure is code.
All of your code, or at least the infrastructure code that I
use to build a new customer environment, is built in
Terraform.
Cloud environment configurations, that Terraform code is
checked into Git.
This facilitates repeatable infrastructure.
And then from my side is an operator of our cloud
environment.
It allows for drift detection and remediation so that we can
keep all of our customer environments tied together.
We have threat, intelligence, and detection.
This is mandated through our ISO 27001.
I just switched from Lacework to Sysdig.
Sysdig, I want to give them a shout out as our
customers as well.
Great product.
Thank you, sir.
All right, but this is cloud control plane monitoring
through the cloud audit and GCP or cloud trails in AWS,
depending on cloud you prefer.
And then we run an agent on every single one of my systems.
That gives us a very rich set of telemetry that we can use
to look for things going on in there that may not need to be.
Logs and alerts are monitored in triage,
put on my 24/7 NOC SOC and DevOps team, mandatory 2FA on
production access.
So we use role-based access.
It's not blanket permissions, right?
My developers don't have access to every system out there.
They say, hey, I want to access Sysdig systems for eight
hours in order to do this analysis.
And this isn't my laptop show.
I can't show you.
But we have a Slack bot set up in a channel called
permission request.
You say, hey, at Gandalf, which is the name of that agent,
I am seeking access to these systems for this many hours,
for this purpose.
And this generates the access log that I present to our
auditors.
We go through our audits.
Yep, the approval list for those access is maintained and
get.
So if you need access to a new system, again, it's going
through mandatory 2-factor.
Hey, or 2-party review.
So it's not just you getting access.
There's always someone in the loop.
And then if you're on the approval list and get, by that
permission request bot that I mentioned, you are granted
access to that system on a time limit of basis.
Today we're using junk cloud to enforce 2FA.
And that's how I facilitate connection in there.
I'm looking at alternate solutions.
And then once again, cloud EPC, isolated environments.
So we can keep everything tightly coupled.
So a couple of advanced security features, and I'll go
quickly for this.
We do monthly security audits.
And this includes access to requests, internal and
external network scans, vulnerability, review,
and remediation.
Everyone inside my company is through a mandatory
background check.
And that includes both employees and contractors.
We do not provision access in Google Workspace, Slack, or
GCP unless you have a successful background check.
Encryption and to malware, you know all the stuff that's
required by SOC 2 and ISO.
And customer data access is willing to do a small list of
flight listed employees inside.
Yep, 24/7 we do it.
All right, we're looking at it.
Code coverage, watching GCP, looking for updates, the
laugh results, and log monitoring.
Pops up in Slack, and get a validated incident.
Goes up to Jira.
And again, I get audited this on an annual basis, if not more
frequently.
Got a bunch of tools we used.
Needless to say, time I won't read through them.
But I'm on the hook for our audits.
So auditors will look at our ISMS.
Let me see if I can pull this up real quick.
Here's my SMS.
This is what I built here.
All right, this is 120 separate policies that cover
everything from--
we got statement of applicability, segregation of
duties, guidelines, your threat and
intelligence process, your information asset inventory.
And yeah, it really sucks when you have to pull these up,
read through them one by one with the auditor.
This is what got me through my ISO.
Hold up.
So yeah.
Get back in this.
Let's see if I can do this.
Oh no.
One more second.
Excuse me.
Oh no, I did it.
I think I closed the wrong window.
Do you know how to pull that back up?
I think we might have to--
Just move on.
Or just open it back up.
Yeah.
This guy.
[INAUDIBLE]
OK.
Thank you guys.
Yeah.
Drag it over.
OK.
That's my show.
I didn't expect that to happen.
That's what I get for not trying to do.
All right, here we go.
Yeah, the double.
Yeah.
OK, cool.
[INAUDIBLE]
[INAUDIBLE]
All right, let me finish this.
I'm almost done.
OK, I was--
Yeah, I got my last slide here.
Last slide here, right.
We built our models.
Alex just talked about this.
We sell post them, right?
We have a subset of features that may leverage
J&M models like case summarization, responses cis.
Use those models are optional.
Some of my customers are very suspicious of J&M AI.
And I will not tell you they're wrong, right?
It's how you choose to deal with the data security
inside your organization.
So if you don't like them, we'll lead those features off.
Look, no J&M AI, right?
Then it was just models running on my hardware.
We can also swap those model providers.
Open AI, chat GPT, anthropic cloud,
and when the process of building some home-built models
on AWS BreadWalk.
Can you take a raise?
Scared is not just a checkbox.
This is the foundation of trust in our enterprise.
We understand the importance of your data.
And we spend a lot of time, effort, and money
keeping it secure.
You have a comprehensive security architecture
to keep your trust, maintain protection of that data,
and have a multilayer, defense and depth approach
to maintain assurance.
Please, contact us if you've got any information.
Thank you guys for your attention.
I hope I didn't get too fast.
If you have any questions, now's the time.
[BLANK_AUDIO]