Understanding Cyber Engineering to Build Stronger Security

Michael Magyar: Having a strong defense looks very different today than it did 20 or 30 years ago.

Jara Rowe: Gather around as we spill the tea on cybersecurity. We're talking about the topic in a way that everyone can understand. I'm your host, Jara Rowe, giving you just what you need. This is The Tea on Cybersecurity, a podcast from Trava. I came across this term cyber engineering, but if you're anything like me, you may not have a great understanding of what that actually means. If you are that way, this episode is for you. I have a returning Tea on Cybersecurity guest, Michael Magyar with us on this episode, and Michael is going to help us understand what cyber engineering is, how it connects to security and compliance, and why it's becoming more and more important. So let's dive in. Hi, Michael.

Michael Magyar: Hey, glad to be here today.

Jara Rowe: I always love your expertise on these episodes. So in case someone hasn't heard you before, please give a brief intro.

Michael Magyar: Yeah, so I am a cybersecurity architect, cloud engineer, penetration tester and vCISO. That's a lot of different things that I just said, but my experience is pretty varied in this industry and so I try to bring a perspective from all the different aspects, whether it's more managerial, governance wise, or whether it's really detailed into the engineering aspects of what we do here. And so I try to bring all those things together and make sure that we can see these from a different picture. So talking today about cyber engineering, that's one of my favorite things to do. I spent a lot of time as a cloud architect, AWS engineer, but I've also built out networks and built out systems and active directory clusters, and you name it, I've probably worked on it.

Jara Rowe: Yeah. All right, fantastic. If this is one of your favorite topics, I can't wait to dive in. So first question, what is cyber engineering?

Michael Magyar: Yeah, that's a weird one because I'm not sure there's a really well- defined term of that. What I will say is I will separate the concept of engineering from other aspects of an organization. A lot of times you'll have people who are making decisions at a high level, either C- suite or VPs or directors, and then a lot of times you'll also have project managers or just general managers who are overseeing the implementation of the directives that come down from above. But at the end of the day, somebody has to actually go and do those things. If we say that we need to implement this new system, if we need vulnerability scanning, or if we need log management or endpoint detection and response, somebody has to actually go and do that. And so, where I see that term cyber engineering coming into play is who is that person that's actually pushing those buttons and implementing those things that we decide we need to do. Cyber in general though is kind of a generic topic and so really it depends on how you break that down into the goals of the engineering engagement to say what type of engineering it is.

Jara Rowe: All right. Fantastic. How does cyber engineering relate to security and compliance exactly?

Michael Magyar: Yeah, security and compliance a lot of times have overlap. They're also a lot of times very different from each other. There's also general engineering. So if you're a company that builds a web application that your customers log into, you have developers and we could call those engineers, too.

Jara Rowe: Okay.

Michael Magyar: And then there's... Yeah, so there's nothing different than building a system, that person who's typing the code into the system, who's actually configuring the controls and creating a network and creating server policies, so that's all engineering. Where we see security and compliance engineering being different is rather than building that web application, a security engineer might be trying to make it more secure, obviously. So that might look at maybe we're improving authentication or maybe we're adding a web application firewall, maybe we're adding logging and monitoring, or maybe we're doing stuff around that web application to try to detect compromise or block when instances of compromise happen. Compliance engineering though, different than security engineering, a lot of times is focused on a specific standard. Maybe you're going for SOC 2 or ISO 27001, or maybe you have a department of defense contracts and you CUI and you have to do CMMC or inaudible, right? So compliance engineering a lot of times overlaps with security engineering because it's going to do similar things. Maybe the compliance framework requires that you have logs and that you do monitor them, and so there might be a goal of trying to build that out as a compliance engineer. But a lot of times the compliance engineering is more focused on policy, procedure, like, creating the documentation that surrounds what we're already doing in a security program. Sometimes an organization hires just a cyber engineer and they do both of those things. Sometimes organizations have two different teams, one focuses more on compliance and implementing ticketing systems and implementing approval processes, whereas another team is more focused on remediating vulnerabilities and making a system stronger.

Jara Rowe: All right. Yeah, that's super helpful because as I was researching about cyber engineering, I did see cyber engineering, compliance engineering, and security engineering all floating around and I didn't really understand what the difference were between them, but that's helpful. Okay. So I know the cloud, the magical cloud, is really important for a lot of businesses right now. So with many companies moving to the cloud, how critical is it that they get the engineering piece right, especially early on in the development of the company?

Michael Magyar: I think in general, organizations just have needed more and more security and more and more compliance and that just has coincided with all these cloud systems and the move to the cloud. I think we see a few drivers for this. I think one is that attackers are more sophisticated and having a strong defense looks very different today than it did 20 or 30 years ago. 20 years ago, you might patch once a year if you patch it all. Whereas today you need to apply patches within 24 hours, otherwise they're being exploited. Attackers will disassemble the update and see what the vulnerability is and then take advantage of it. I think we're seeing this need to become more secure and it's just accelerated the speed and the level of detail we have to put into our security. I think separately, we see the supply chain getting a lot more credence than it used to or a lot more significance. Organizations are requiring things like SOC 2 and ISO 27001, and so now you have to implement those things. Those frameworks have been around for a while, but it's this weird momentum has been building over years and so those are now becoming table stakes to do business. I think part of that is because when you have a framework that requires other people to implement that framework, it's easy. It's almost like a Ponzi scheme where it keeps on pushing it around to everyone. So we're seeing SOC 2 and ISO 27001 drive a lot of this. We're seeing FedRAMP and HIPAA and CMMC now all driving this need to be certified or at least to be compliant with the framework. PCI, same thing. So I think that's coinciding with the cloud, but I think that those are the actual drivers of why we're seeing more of a need for this. I think with the cloud though, there's a lot of complexities and each cloud looks very different. They all are complex in how they deal with their own ways of authentication and the different security things that we have.

Jara Rowe: For sure. Having someone that understands the difference, like, the nuances like you were just saying, that seems like a lot. So yeah, definitely needed for sure. So one thing I hear a lot, particularly when it comes to engineering or developers, when you need a certain compliance certification, they're like, that's getting in my way of doing what I really want to do because it has to be done this way. So how do you avoid making a system so secure that it becomes annoying or it stops people from doing their actual job?

Michael Magyar: Oh, I could talk about this for days, but I'll try to keep this short and simple. I think most organizations take the wrong approach, and this is getting into we call architecture. So if you think about the difference between an analyst and an engineer and an architect, an architect is deciding how a system should look. A lot of times they're also implementing it and maybe managing it, too, if it's a smaller company, but an architect usually decides how it should look, an engineer will implement that, and then an analyst will operate it. When organizations don't put enough effort into the architecture piece, they can really hurt themselves long term. Most of the frameworks that we work with have a lot of flexibility. So if we're doing it from a compliance standpoint, a lot of times there's... SOC 2 says you have to have monitoring. What does that look like? That can look different in different places. We're seeing a lot of GRC tools be very opinionated about what that means and that's good because that gives guidance to companies that don't know how to decide that. But there are a lot of times half of what I do in my vCISO/ engineering work when it's a compliance engagement is just discussing all the different findings that a compliance tool has and trying to decide does this actually have an impact on your security and is this actually required for compliance or maybe are you doing that a different way? So I think the first thing to do is to understand the goals and the actual requirements from a security standpoint and a compliance standpoint, and try to decide are we meeting those goals and accomplishing our security goals in a different way or how are we actually doing that? We have this concept of security theater and I'm going to use that as a derogatory term, but basically are we doing that because it's actually making us more secure or are we doing that because our CEO had some other CEO tell them they should do that, and so now we're doing that, or because this is what we think this compliance framework says. But I think what's interesting is when you take a step back and ask yourself, what is the actual requirements? A lot of times you can decide what your current business operations are and try to fit that in more effectively. When you do that, you're not hampering your business operations when maybe there's five ways to accomplish the same goal. If you have smart architecture, you can choose the one that fits best with your business.

Jara Rowe: Security theater. I had never heard that before, but I love that term. Yeah, but we don't want to act do stuff just because it needs to be legit and meaningful.

Michael Magyar: Exactly.

Jara Rowe: Okay. So can you share an example, maybe, like, a real world example, how cyber engineering helped a business avoid a problem or even made something easier for them?

Michael Magyar: Yeah, so I'll try to give you not too many because I could go on for days.

Jara Rowe: Yeah.

Michael Magyar: Here's a really obvious example. Organizations just continuously add new systems. Maybe you have your productivity tool, Google Workspace or Microsoft 365 for email and files. We also have a lot of other tools, whether it's our cloud provider for our application or maybe we have a password manager like OnePassword or LastPass, right? I can go on and on. We have tools like ClickUp or Monday or all these things to do productivity and we just... So many different tools that we're dealing with here from a marketing, HR, and IT and everything standpoint. So one question is how do we deal with identity in those different systems? How do we deal with usernames and passwords? When someone's onboarded, I have to create a user at every system. When off- boarded, I have to remove them from every system, and that has both security and compliance issues. Compliance wise, I have to know who my people are and have authorized users in most of these frameworks, and I have to make sure that people who are authorized are still authorized and should be. And so I have a compliance requirement. I also have security. I need to make sure that we have strong passwords. Maybe we want to make sure that as we off- board somebody from the organization that we remove their account and remove their access, otherwise they can grab that data later, especially if it's an involuntary off- boarding, right, like a termination. So we can spend all this time and build all these procedures where every time someone's off- boarded, we go through this giant checklist of all these systems and make sure that they've all been off- boarded and check a box next to each one on a form. We could also just set up single sign- on. And so if we set up single sign- on and we have a centralized identity provider, and it's funny, Google can do this for you. So if you have Google Workspace, you have the ability to do this. Microsoft 365, Entra ID. If you have Entra ID P1, it can also do single sign- on with SAML and Olaf. So there's a lot of these tools that we already have that can do centralized identity, but a lot of times people will buy Okta or other ones, too. But if we centralize all of our systems into one identity provider and they'll trust that identity provider, when we create a new user, we can set up, it's called SCIM provisioning, where it pushes that user out to the different systems that are supposed to exist. So now we just accelerate our operations, but there's a security benefit because now they have one password for their centralized identity provider, so they're not having to manage the passwords themselves. They're not writing the passwords down as easily on sticky notes or using the same password for all these different systems. And when we off- board them, hopefully that doesn't happen soon, but if they decide to leave or we decide they need to leave, we can turn them off in the centralized identity provider and now that just blocked access to everywhere else. So I can give a lot of other examples, but I think single sign on is one of the easiest to understand why smart engineering is smart architecture can save a lot of time and money.

Jara Rowe: Absolutely. I started the episode with saying I have no idea what cyber engineering is, not knowing that I use something that was smartly cyber engineered every day in single sign on. So that was the perfect example, for sure.

Michael Magyar: Excellent. I'm glad I made that simple to see.

Jara Rowe: Okay, so AI, artificial intelligence is the hottest topic in any industry right now. So how is AI changing cyber engineering or influencing it in any way?

Michael Magyar: AI we have to remember is simply an averaging system. AI is not this independent thinker that, it's not like some philosopher that's going to give you this new insight on life. It's really just taking existing data and when you give it information, it tries to pattern match that data that you gave it to the other data and then provide a response. And that can be correct, that could be incorrect. It's kind of a guessing system. Now, it is amazing the technology. If I need to build a PowerPoint slide and I need a picture that's kind of crazy, but I can push a button and get something that looks pretty good when you're not really paying attention to it. I can see this, wow, look, that looks great. The problem with AI is when you start looking into the actual quality of the work, it's usually very poor. And we're seeing this, like, how many figures does that person have in that picture that I just generated? Why is the text all garbled? It doesn't look right. So AI is really good at generating noise that kind of looks like what you want. And so, I think it's not really good at accuracy. Maybe you'll get better over time. And again, it's amazing what it can do, but we're seeing a lot of developers struggle. Their day is no longer writing code and designing it in their head, it's a struggle just to fight the AI system to get something that works. And so a lot of people are using it and accelerating what they're doing, but they're also turning away from it on things that really matter that they have expertise in. And so, getting back to cyber engineering, the first thing we have to realize is something called MCP. And so this is a protocol that allows AI agents to connect with other systems. So we are seeing AI becoming, it's called Agentric AI, where we're basically... It's an agent, it can do things on your behalf, it can book that flight for you, it can write that code and just push that pull request right out to GitHub for you. It can connect into your identity provider and create a new user for you. That's kind of scary. But you take what I just said about quality and we realize that AI is a really confident intern, somebody who's willing to say, of course, I can do that. This is definitely the right answer. But they don't have the experience to really... And interns are amazing, everyone needs to learn, right? But the AI system is confident in its answer that's also kind of randomly generated based on pattern matching. And so, when there's a new system that doesn't have any content out there to pull from, the AI system doesn't know how to interact with it. If let's say AWS comes out with a new service offering, how does the AI know how to do anything with that if it's never had that body of knowledge that it can ingest for training? So we have problems with new things where AI can't do that for us. And then just the quality side. If I need to generate a bunch of junk, AI is amazing. If I need one button pushing exactly the right way, it's very scary to rely on the roll of a dice. So I think AI is accelerating the things that we can do. I think AI is changing the fact that I'm not just using Google to figure out how that thing that I said I could implement, how that actually works true. Also, honestly, I don't want AI just randomly creating users or deleting users for me because it can make a mistake and just delete everything, or it can make a mistake and make it insecure. So I think what we're going to see as we go forward is more people be relying on that as a way to have a cheap workforce, honestly, and just kind of downsize and save money on people. But I think what they're going to do is actually create a lot of problems for themselves and they'll layer other systems on there to... Well, we have a system to create users and we have another system to validate that users were created properly, but then we have another system to validate... We're going to have all these different systems fighting each other. At the end of the day, we just needed someone to push a button and say, create user. So sometimes there still is a value in having somebody to go in and say, let's create that user. So I don't think engineering is going away, but I think it's going to change just like everything, and look a little differently, but I think it's still going to be required.

Jara Rowe: Great. So any other trends you see coming? And then how do you think a business should prepare when it comes to cyber engineering?

Michael Magyar: I think we are seeing more and more specialization. In general cybersecurity or just even the technology systems that we use are just changing so fast and there's so many different options out there. And that's been always true. When Active Directory came on the scene for Windows, that was a big deal. Right? And so everything's changing all the time. It's just that it's changing so fast and there are so many systems, it's hard to keep up with that. So I think it's harder and harder to be a jack of all trades. You really will be a master of none. So I think that means organizations are going to continue to need to look for specialized experts in the systems that they're using so that they can focus on doing what they do as a business. Focus on your business logic. I think the compliance side is really an interesting thing, too. And being smart about how you implement a compliance control that doesn't hamper your operations, I think is really important. And so I think those are probably the most important things. As far as how an organization can prepare, I think organizations should look at the systems they have. First of all, get rid of the systems you're not using. I just said there's too many systems, right? So if you have 100 systems, are you using all 100 systems? Because now you might need an expert in each of those systems, and that's really expensive. Can we consolidate down? Can we get rid of half of those systems and not need an expert to come in and configure them? And that can save us a lot of money and make us more secure by having fewer things to manage and more client because we have fewer things to have to pull evidence from. So I think being intentional about the systems you have and use is important. And then being intentional about how are we making sure that these are configured properly?

Jara Rowe: Yeah, definitely. Okay, Michael, so I'm at the end of my questions, but again, I know you're passionate about this topic, so is there anything else you want to cover or really make sure that people understand before I let you go?

Michael Magyar: I think it's important to both know when you need external help, and also to realize that you don't always need external help, and you should be smart about that. Sometimes you get sold snake oil of this person's going to actually do all this stuff for you and maybe they're fresh out of school, which not to be derogatory about, everyone was there once, but at the same time, be really intentional about the things that you're doing. And simultaneously, don't be afraid to get outside help if you can find someone who really knows what they're doing. And just because they have a bunch of certifications or experience doesn't know that, so vet them, ask them questions, make them explain to you what you're going to do and why, and then you'll really understand if they know what they're talking about or not.

Jara Rowe: Absolutely. All right. I appreciate your time. Thank you.

Michael Magyar: Yep, thank you very much.

Jara Rowe: Now that we've spilled the tea on cyber engineering, it's time to go over the receipts. I truly learn a lot about cybersecurity and compliance from hosting this podcast, but I will say I got the clearest understanding of what cyber engineering is through my conversation with Michael. So I'm going to leave you with a few takeaways. First, is what is cyber engineering? And Michael did say it's not well- defined, but when you think about it's the work of protecting technology. So cyber engineers, they guard things like our systems, our information, and they also build things, which makes it related to security and compliance as everything needs to work together, which we've learned several times in these podcast episodes. And he also said that when you really think about it in this instance, developers can be engineers. My next receipt, I asked Michael specifically about how cyber engineering relates more so to companies when it comes to the cloud. He let me know that it's as crucial for everyone, whether it's cloud or not. He just pointed out that it's more important for companies to think about security and compliance as enterprise customers and things like that are beginning to require more compliance certifications like SOC 2 and ISO 27001, and even things like our privacy stuff, like HIPAA. So it's just crucial across the board. When I asked Michael about an example of cyber engineering, he talked about single sign- on as it's a centralized identity provider and it's related to both security and compliance, which has to be cyber engineered as they collide. I also asked Michael, who actually does the cyber engineering, and he said that the person that actually creates the code or presses the button. So as I mentioned a few seconds ago, it can be a developer. The architects also have a hand in this. And when I asked Michael about how he thought cyber engineering would be changing over time and he really honed in on the fact that it's going to be become more specialized, like, there are going to be cyber engineers that are more specialized in SOC 2 and all of their requirements when it comes to GRC tools and everything else in between. So we will see more specialized roles in cyber engineering. I hope you learned as much as I did from this episode of The Tea on Cybersecurity. I'll see you again soon. Thanks. And that's The Tea on Cybersecurity. If you like what you listen to, please leave a review. If you need anything else from me, head on over to Trava Security. Follow wherever you get your podcasts.