Simply Solving Cyber - Ben Phillips
22 Mar 2021 · 28 min
Ben Phillips, Director of Audit and Assurance at KSM, moved from financial audits into IT controls and SOC reporting. He breaks down SOC 1, 2, and 3 reports, warns against generic policy packs that don't match actual controls, and says privileged-access-management tools often get deployed without proper risk assessment first.
Chapters
Welcome or welcome back to Simply Solving Cyber. This is Aaron Pritz.
And I'm Teddy Guzik.
And we are excited today to be talking to Ben Phillips, Director of Audit and Assurance at Katz, Sapper Miller, based in Indianapolis, but a national practice. So Ben, welcome to the show.
Thank you, Aaron. Thank you, Teddy, for having me.
Yeah. So like on every episode, we want to start focusing on you and your journey into cyber and all the tentacles around assessments and audit and assurance that persist with that. But give us a little bit of background on how you got into this and what you do today and so on and so forth.
Yeah, sure. Would be happy to. So honestly, it was the wrong place at the right time. So being where I come from, born and raised in West Lafayette, Indiana, went to Purdue University, 2 years out of college.
Wah wah.
Oh, sorry. Teddy and I are IU guys, so I have not used that button yet, but I'm glad that I found it so quickly.
Perfect. So yeah, 2 years out of college, I found myself in accounting, was auditing. I started out auditing publicly traded companies. So as part of auditing publicly traded companies, Sarbanes-Oxley is a big thing. Yeah. As part of Sarbanes-Oxley, there is an IT audit component. You have to understand, you know, the financial controls, but also the IT systems controls that impact the business based on a financial reporting framework. And we had, we had some turnover as you usually do in public accounting. And a partner said it would be a good opportunity. Opportunity always means a good piece of work. So it was good though, because it enabled me to really jump into— you can audit debits and credits. Can you come up with— gain an understanding of IT risks? Same thing. Use sampling to gain an understanding of something I never did before. So that was the fun, fun way I got into it.
Cool. So any regrets? Do you want to get back to accounting someday, or do you like the controls cyber angle? It's definitely hot right now.
Yeah. No, no jump to get back. Back into— I'm not going to start doing taxes. I have an amazing team at my company that does that.
Nice.
I still have a CPA. It's required for what I do. But if you want to talk tax, if you want to talk financial reporting, you want to talk audit, you got a guy or a gal. I got a bunch of guys and gals, you know, 5 miles down the road that will very easily talk your ear off.
Nice, nice. Yeah, like within the audit practice, a lot of people got into audit, especially if you've been doing it Within the last two decades through Sarbanes-Oxley. And actually, when I was in the corporate world, I did do a stint in audit for 3.5 years. I don't even know if we've talked about that before, but I dodged Sarbanes-Oxley because of a privacy issue where we needed to build a privacy audit practice. But I did do a little bit of SOX and it is, it is an interesting topic that's been around for a while. But yeah, so beyond SOX, how has your practice and the various companies you've worked for, how have you evolved in the space of cyber and controls around protecting data?
Yeah. So what I hit on initially was how did I get into IT auditing? Right. And that's because certified public accounting firms audit large companies, right? Those large companies have to be in compliance with SOX if they're public. But another thing that, that I learned being somewhat naive as to gaining this skill set is only CPAs can also do this thing called SOC reports. And the firm that I was at also did SOC reports for this publicly traded company. So it was a pretty nice segue into— it was 2012, 2013. SOC 2 came about in like 2009 or 2010.
Yeah.
So 3 years in, I was able to dive into what is this, right? As a bright-eyed, you know, bushy-tailed staffer.
Speaking of bright-eyed, bushy-tailed, and the layperson that may not be into the audit game, many companies have heard about SOC, and I've heard a lot of confusion around SOC 1, SOC 2, a lot of numbers, a lot of acronyms. Yeah, break it down for us. Help our users learn so they know. A lot of times companies ask for something and they— what they really want is something they don't understand yet.
Yeah. Yeah. So my favorite thing is I saw this 2 days ago in a master services agreement for one of my prospects. So the large company that they're working with said they have to be SSAE 16 certified by XState. It's now SSAE 18. And that doesn't— and that's just a standard that defines what a SOC report is. So to easily answer your question, right, there's SOC 1 and SOC 2. SOC 1 is a report that covers internal controls over financial reporting.
Okay.
So the end users of that report would be management, but as well as the, like, the financial statement auditors that would be relying on the information that's coming out of that system to support their audit. So think of a payroll processing system. Companies put information in and it basically withholds a bunch of money and then gives them entries to plug into what different general ledger buckets to put into it. That's SOC 1. It really helps with internal controls or financial reporting.
Okay.
SOC 2, on the other hand, which is a bit newer, way more exciting and a lot more honestly with the market. I haven't had a new SOC 1— well, actually one this past year. SOC 2 has been much more emphasized with regards to information security risk, supply chain risk, right? And as well as just, just new companies coming up with new solutions and solving new problems with data. So SOC 2 is an internal controls report, independent also. However, it covers areas such as security is required, but the other 4 categories are confidentiality, availability, privacy, and processing integrity. So both reports valid, but 2 different subject audiences, right? One's hitting security and data, and one is hitting internal controls over financial reporting.
Okay. And is there a SOC 3 patent pending?
There is a SOC 3. Oh, there is a SOC 3. Is actually— there's other 2 other SOC reports. Types that we're not going to get into today. But SOC 3 is essentially a SOC 2, but it has a lot of the— has the testing section of the report removed, as well as certain information within the description removed. So it can actually be used as more as a marketing flyer. So you can— like a SOC 2 report, you can't just post that on your website. Your auditors wouldn't like— it's restricted to their clients, to the user entities and prospects.
Okay.
However, SOC 3, they take away all that, that gooey intricacies that only a selected audience should be able to interpret or know.
So it's— I was going to make the joke that a SOC 3 is one better than a SOC 2, but I feel like from your description, a SOC 2 is still the workhorse SOC.
Yeah. So essentially, if you get a SOC 3, you're already getting a SOC 2.
Got it.
A SOC 3 is just a way to, to better publicize it. However, it's not in the market. It's not used that much. AWS has a publicized SOC 3. Very large organizations do, but it's just not something that a lot of companies that need to get a SOC 2 just for a compliance requirement are just going to let everybody see how they do what they do.
Yeah, that makes sense.
So you started off in financial accounting, you moved into IT controls. How many, how many different steps have you taken along the way? Have you worked at many different organizations? Is it just one?
Yeah, so I started actually, I started my career in Indianapolis at Katz Zapper Miller right out of college, worked here for a year and a half. My parents went to London, my sister went to New York. I was an Indiana boy. I tried to get out and see the world. So I actually went and worked in Minneapolis, Minnesota, worked for a firm there for 2 years. Minneapolis for 2, Chicago for 3. That's when I got embedded into IT audit.
You've just been migrating south again after the -40 in Minneapolis.
100%. But if you ask my wife, it's because I came back here.
Ah, yeah, she's here.
But I'll stick with that. Yeah. And that is probably the right route to stick with. But, but yeah, so I did that in Chicago with the same firm, ventured back down to Indy, joined another large national practice, top 10 CPA firms. PA firm, was a leader in our IT risk practice. My teams did high trust PCI, SOC 2, independent auditing of SOX controls to support the financial audit. And then actually joined KSM January of 2020.
Rejoined.
Rejoined KSM. Rejoined Katz Zapper Miller in January of 2020, right before the epic February that came with it. It's been good ever since. So I've enjoyed it. It was nice that I knew everybody before I came back.
Yeah, very good. The next thing we always like to talk about is cybersecurity in general probably overfocuses on technology and tools and buy this silver bullet to solve all your world hunger. And the thing that maybe gets undershadowed in the industry is a focus of people, process, and people, process, technology is of course the triad. But again, if technology gets all the play, you can sometimes underappreciate the skills that require people and process. So in every show and every guest, we always like to ask a good story question of Tell me about a time where people and process saved the day and really differentiated where a tool couldn't have magically solved the world hunger that was facing a client or an organization that you're working at.
Yeah. So I would say quite recently, one of, one of the examples was you can always go out and buy a tool to fix a problem. In this world, you can also go out and buy a service to fix a problem. In my world, doing SOC 2 audits over security, one of the, one of the more important things is as a result of being done, as a result of doing the critical things like, one, do you know, having an information security risk assessment, understanding who you are, understanding what kind of data you have, understanding what your risk tolerances are from that initial onset and what your business does, then you would develop policies, procedures, processes to meet those needs, solve those risks. And that's in a perfect world, as I'm sure you can attest to, that's how it should work.
I can't attest to because I'm not a CPA, but I know what you're saying.
But In some circumstances you can also buy, you can pay a service to have a company provide you with basically policies, procedures, etc.
Oh, the classic in a box. Here is your ready-made policy pack. The policy pack.
Yeah, exactly. So I acquired a client and they had a policy pack. They had a SOC too previously. But so when I come in, I read their SOC report, I ask them what they're doing. They had a lapse in SOC reporting, which usually doesn't happen that much. They had some management turnover. But essentially went through the stage of doing a readiness forum to help them get ready to make sure that they were doing all this stuff. Got a dump of their policies and just straight out asked them, are you doing this? Are you doing this? Are you doing this?
Yep.
Look at our policy. Are you doing this? No.
Yeah.
From an audit perspective, that's a problem.
That's almost worse than not having a policy at all because you're claiming to do something which you're not, which back from my audit day again, if somebody needed the coaching and the development to get something in place, that was easier than, hey, you've claimed to do this, you've probably even passed some external assessment type things, and then it's not reality for whatever client that you're serving. So totally get it.
So the, so the problem, right? They had dormant policies that they procured probably quite cheaply, passed an audit once, quit doing it. The key stakeholder had left, and now where are they? Their client still wants a SOC report. So how did people save the day? They leveraged some third-party vendors that they already had trusted. They brought somebody in— wasn't me, just because of independence reasons— to better understand what they're doing and how they're doing it as a result of the readiness assessment. And from that, we developed a— they developed a slightly retooled controls framework based on what they actually do and what their risks are, remapped their policies to make their control statements actually actionable. Yeah, versus in real, in real, they had, you know, some controls that they had previously had just didn't align with the risks of their business and how they run their business. So it's more, they are a more secure organization, they have a better pulse on it, and they're able to do it in a fashion that they're actually able to breathe and react versus just, oh, we got to go run to this meeting to run to this meeting to run this meeting just to be in the sake of being a meeting.
Yeah. So how do you coach clients? Because sometimes the age-old policy pack or finding an accelerator, somebody that's done something before, that can help. But what I find is you have to tailor it. You have to make it real for your business. How do you prevent people from buying these policy packs or insert your process in a box and just flinging it out and calling it done? How do you coach them to avoid that failure mode that you saw at this one specific entity?
Yeah. How do I coach them? I just have a conversation initially with everybody involved to say, hey, let's get this on the table. What are we doing here and what's the best way to go about it? I think it's fine if you want to, if you want to get a place to start. But the simple answer, I read the policy, I read the policy and have a discussion.
All threads. That's what I—
you got to do. Yeah.
Are those discussions usually pretty difficult to have with those stakeholders? Are they usually trying to— we've been doing it this way for a long time. It's a lot easier this way. Why can't we just turn our eye, that kind of thing?
Yeah, usually it's— they have tried to do that before, but, but I just ground it with, hey, you paid us for an independent audit. We're a CPA firm. We're doing stuff by the book. And for that reason, we can't— we— I can't preach what we're not practicing. It's really easy because a lot of times when you're having these discussions with certain stakeholders, this is unlike anything else that I've ever audited before, like finance. You can go to a company and people are very— even CEOs are very comfortable with talking about revenue, P&L balances, how things get done, how deals get done. What a lot of people are not comfortable with doing is talking themselves away around security risks because they've never done it before. So I'm just like, I don't try and fear them, but I just say very simply, doesn't— based on the conversations we've had, it doesn't sound like we're doing this. So if that's the case What's the action plan?
Right.
And I just very blunt, like in the most professional manner whatsoever, just say that. And I just ask him straight up, are you doing it? Because if you tell me that, if I'm not independent, if I'm doing a readiness or a consulting ahead of time, I can help you get that story straight before you get formally audited. But once we are auditing you and we are independent, any findings I have, it's going to go in the report and then I'm going to have to work with you on how to respond to it. So it's a lose on the second scenario.
Would you say over the years it's gotten easier to have those conversations as people are more aware of security risks and, you know, what their ramifications are?
Good question.
Yeah, I would say it's got easier to have those conversations with the same client that I've had that conversation with. However, each client is on their own journey. Yeah, so it depends on what they've been doing in their whole life. Like, a brand new client is— it's always difficult to, because it's hard The most difficult thing is sometimes individuals that are responsible for this stuff, a lot of the times you'll have a chief operating officer that'll be overseeing a lot of this kind of things and they'll leverage third parties. Security and technical things and technical risks are not their core competency. So it's bridging that, like, that technical what-if scenario. And also sometimes if it's not their thing, bringing in someone that can digest it for them, but put it in a line of sight that's in layman's terms, getting hacked. There's a bunch of different technical ways you can talk about it. Getting hacked or what, like what Ryuk means or what other different ones mean. But if you actually talk about what happened and how it happened and what the result was, it's a little bit easier to stomach than technically. Yeah. How did you know? How did it happen?
Yeah. Yeah. I have two audit-related scenarios or questions for you. One, when I was in internal audit at a large Fortune 500 company, we did a fair amount of vendor audits as part of our annual audit plan. And one of the vivid things that I remember was sometimes the controls in place, especially on the pre-assessment or the pre-work that we asked for, they would be legit policies, probably had a policy package of some kind, or more likely they had a parent and child company relationship. So maybe the corporate parent company had policies that didn't necessarily transcend down to the child that was actually doing the work that— this was probably 15 years ago that I was in the game there. But what's your thoughts on that? And how do you help both on the client side as well as the, maybe the companies that are looking at their third-party risks? How do you help them avoid like misrepresenting controls when it may not apply to the client at hand?
Right. So if I heard you correctly, in your scenario, you had a parent company with amazing policies that apply to their entity-level environment, right? And then you had some sister subsidiary companies that Maybe we're acquired later and that's the easiest way to consider it. So how do you— honestly, their goal in that acquisition was to get the subsidiary company aligned on an enterprise level.
Always easier said than done.
Easier said than done. But there's a step-up approach, right? And it's difficult. And that's probably where in that general scenario is where I would advise the client of what's difficult here. What does being done looks like? And, and then how do you, how important it is to, as you're venturing down this journey, to include that larger parent entity in your endeavor. So there's no miscommunication between when you get a report, what are you doing versus a discrepancy between what your parent is doing. So it's honestly the easiest way is communication.
Yeah, no, that's great. My second audit-related scenario would be, and I'll pick a random cyber technology just to play the people, process, technology thing together. So let's say privilege access management. I've done a lot of authoring, content authoring on that topic, but privilege With privileged access management, it's easy to buy a tool and then there's all kinds of layers of what implementing that tool would be and across what assets have you implemented it. So for example, you could buy a big one of the mainstay tools and you could just implement vaulting or you could do the pass-through where you can automatically log in and no one ever has to see a password. Or you could do pick your next 5 advanced features and then the scale of the organization, how many applications have ingested those controls? Or is it the build it and they will come scenario where you've built a tool, you've set up stand up a service and nobody's adopted it. So from an audit standpoint, how do you help companies avoid thinking they've met the finish line when they buy that tool and stand up the service when they've not yet done the hard work of getting that rolled out across the organization where it matters?
Yeah, hopefully, in my opinion, I would hope I could help the client before they would procure that tool. You got to make sure that based on what you do and based on what you're using it for, that it can serve your purpose. So I guess that would be the biggest thing, would be trying to help them make that executive decision on is this something that you need and is it serving all the right risks that you're looking for? Because what you just said is someone spent a bunch of money on a tool and they haven't figured out how to implement it across the board. That's a problem. How would I help a client, or have I helped a client with that? It starts with honestly just dumbing it down to Have you done a risk assessment? If you've done that risk assessment, what data is at scope, at stake? Where is the data? Have you done the data mapping? And then really thinking about, okay, can you use that tool to protect everything? Yeah, but is there a cost benefit to that? Yeah.
You know, where do you prioritize that? You spend your time, right?
Yeah. I mean, like us, we just went to Adobe that has the cloud, the new cloud version. Now I got to enter in my password. Does it make sense for me as a person? At a company or anyone to implement that kind of tool for Adobe. Maybe, but I don't know. And you can't really know until you assess it.
Yeah, definitely not on Adobe Flash. I think it finally got killed a couple weeks ago.
It did get killed. It did get killed. Yeah. So that's what I would say with that. But honestly, rolling it out amongst the entire organization, you got to figure out from a privileged access management, it talks about data, right? Where is confidential data? How is it accessed? Who's it accessed by? You got to do that kind of data mapping and flowing first. And then think about how much time and investment do you want to spend in protecting that? What are you supposed to do versus what actually can you do? Or is there other means to where adding that would just be a headache when you could just go through SSO with multi-factor authentication and serve the exact same thing if it's not easy to integrate?
Yeah. So last topic, and I'm going to let Teddy, if you're okay with this, riff on this because you are 20 years in the market and you're 5 to 6 years in the market, something like that. We won't disclose our ages, but you're much younger than I. But one other topic that we like to get into is like, how do we help people get into cyber and audit and privacy and security? How do you coach young people? Should they start off in audit? Should they jump into IT and cut their teeth on standard way to implement and then go audit it? There's lots of options. There's no right answer, but what is your What are your recommendations for the youth of the world as they get into this field?
Yeah, I would say honestly, it's wherever your heart is, right? If you want to do something you love, do something you want to do. But the best way to get into it— no shout out, but we just hired a new member to our team. And most accounting firms and most auditing firms, they hire from other audit firms. And honestly, in this light, like this, it's difficult to find an auditor that started auditing IT. It just doesn't happen that much. Most are transplants from other— like me, you started auditing something and then no matter what you're auditing, you're using risk-based sampling to identify and test something. So we actually just hired an information security analyst from industry that has never audited before in his life.
Yeah.
And we're teaching them how to audit later, which is an interesting tactic. But I would say as far as how to get into it, I know like at least in India, without dropping a bunch of stuff, there's a lot of different cohorts around India. 1150 is a great place where I've seen a lot of people start somewhere else, go through a session, and get somewhat comfortable with that legit skill set. I've also seen there's a lot of support groups that, that just talk about those kind of things as well. There's, there's great organizations like ISACA, Central Indiana ISACA chapter here in Indy.
Which, shameless plug, you know, Ben, you and I are both on the board of directors there, which, uh, we do heavily recommend that organization. Great community, over 600 members within the region.
Shameless plug from the president. There's also other ones, right? There's ISSA, there's— what else is there?
IIA, which is the audit one.
OASP.
OASP, yep.
So it's actually interesting. I know we talk about this every episode, but I just got off the phone today with a student at IU that was calling about career advice, trying to figure out where he wants to go. He's got an informatics degree, or he's going to have an informatics degree. He's a senior right now. Was asking, where do you think I should go? And he was thinking originally traditional IT, and I was over here talking him into cyber. But his initial reaction was, and I bet you guys could both guess this, was, I'm not very technical. I don't— not very good with the coding thing. I didn't do well in my coding classes, that kind of thing. And my response was, there's all these different windows in cyber. And I was sort of getting into auditing, IT audit, and that kind of stuff. And I was having a hard time explaining it to him, to a college-level person. And because that whole entire realm— I went and worked for an audit firm right out of college too and didn't— couldn't tell you what auditing was until like 6 months in there. So how would you explain that to someone at a college level you think would— that you're trying to convince them into getting into the industry and explaining to them it's not super techie, it is a business route in cyber. How would you talk them into that?
Yeah, fortunately this is something I've done a lot. I would say just like financial auditing or anything, you studied, you studied a framework, right? You have a base knowledge of something.
Something.
But no matter where you start, hopefully where you go, they have an expectation that you're going to pretty much learn everything on the job. You don't come, for the most part, into an IT audit career or a cyber career with an audit firm expecting the fact that how to audit the way that they audit. So the big thing for me is you got to look at the people that you're going to work with, and you got to be open to the type of companies that you're going to be working for. And just remember that it's every— everybody's starting from a different place And it's an interesting place to just learn on the fly, learn on the job, and learn something that you don't know right now.
Right.
The beautiful thing I think personally about IT auditing, and I know Aaron is, you can probably attest from your experience doing it, is you're hitting so many different types of domains as part of what you're auditing and you're meeting so many different types of people that regardless, at least after 3 or 4 bouts of it, you know the definitions and you're pretty good and you have a really good understanding of why they're doing what they're doing. Like when I was in public, when I was still in public, the big thing with auditing, like publicly traded companies is the domains is logical security, change management, and system operations. How do you add users? How do you remove users? How do you review users? How do you review password settings? How do you make sure that they're backing stuff up? How do they make sure that they're actually spinning it back up? Just, but, but having those conversations at a client happens with people that have been doing it for 20-some years, but they're all different. So honestly, I think as long as you like to work with people, think about the cool, the The coworkers, the people that you're meeting here today, we're all in it together as we're working through this. And it's a really good place to just, to just learn the entire landscape of what it is. Because if you go look at any like big picture, any big information security program, it all touches it, right? Aside from the governance and the policy and procedure, at the very end of the day, it's how are people at the company doing what they say they're doing? And as an entry-level auditor, you're getting paid to go listen to their story.
Yeah. So on that note, And quick personal story for me in 2004, that's when I was at a large corporation. I decided, actually, one of my buddies said, hey, you should go look at internal audit. And I looked at the job profile and it said international travel 30%. And I was like, sign me up. I didn't even know what I was signing up for. And actually I did have a little bit of fear. Audit, that sounds like I've got to beat people up. It sounds like I got to throw the book at them. Like I had this. Perception in my mind. And what I— my realization was I thought it would be 80% paperwork, like checking things and documenting things. And what I found is it was almost the exact opposite, maybe 20% paperwork and 80%, like you mentioned, especially in an international company going into different cultures and trying to learn how business works in that country. And some countries have different views on like facilitating payments and what would maybe be thought as a bribe in the US is very common in another culture. So I found it very fascinating, but I think my coaching for young people looking to get into it is don't take what you think that Hollywood of a, of an accounting auditor, of the stereotype that it would be there. Because really it's about pulling threads, learning stories, understanding what works, what doesn't work, calling out gaps, and then ultimately helping them lead to fixing those gaps.
Yeah. The one thing that I learned, like initially when I found— I remember when you found your first finding, I thought I was like, uh-oh, they're going to be extremely upset.
But honestly, is pentesting the same, Teddy?
Like the exact same. I mean, half the time when I call a client, I'm like, they're going to be very upset about this. They're like, ah, okay, cool.
It's a day in the life now. You're helping them move past it. A lot of it actually is how do you bring it to their attention, frame it in the right way from my perspective. No matter what I find, management's going to have to sign off on it. But as long as I get the key stakeholder who's responsible for that, I get their story straight so I don't leave him or her sticking out with their tongue out of their mouth. Better way to say it, probably. But as long as they're on board with how I'm presenting it and it's materially accurate, they can learn from it and go from it. And honestly, it happens all the time. So it's not within NIST. There's a, there's a plan of actions for a reason, because something happened.
Indeed. Awesome, Ben. I'd like to thank you for coming out and chatting with us here and really appreciate the discussion. Hopefully we've inspired some people to change their views on audit, get excited about it, whether they're wanting to do cyber audit, privacy, risk, all of it kind of coalesces in protecting companies and data. So really appreciate you coming out and chatting with us here today.
Thanks for having me.