Quality Bits

Security Engineering with Aleksandra Kornecka

February 20, 2023 Season 1 Episode 13
Quality Bits
Security Engineering with Aleksandra Kornecka
Show Notes Transcript

Aleksandra Kornecka turned from a QA into a Security Engineer. In this episode, Lina talks to Aleksandra to learn more about this switch, the importance of security, and its parallels with quality. You'll learn about threat modeling, where to start when learning more about security, and so much more, including some anecdotes referencing the most famous hacker in pop culture - Mr. Robot.

Find Aleksandra on:
- Her Website: https://aleksandrakornecka.com/
- LinkedIn: https://www.linkedin.com/in/aleksandrakornecka/

Mentions and resources:

Follow Quality Bits host Lina Zubyte on:
- Twitter: https://twitter.com/buggylina
- LinkedIn: https://www.linkedin.com/in/linazubyte/
- Website: https://qualitybits.tech/

Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.

If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte

Thank you for listening! 

Lina Zubyte (00:06):
Hi! Welcome to Quality Bits - a podcast about building high-quality products and teams. I'm your host, Lina Zubyte.

In this episode I'm talking to Aleksandra Kornecka, who is a security engineer. We talk about all kinds of misconceptions we have about security, it's parallels with quality. We touch on concepts like threat modeling and discuss how we could increase security awareness. Hope you enjoy this conversation.

Hi, welcome to Quality Bits, Aleksandra. It's really nice to have you here today. How are you too?

Aleksandra Kornecka (00:56):
Hello, Lina. Thank you very, very much for the invitation. It's really cool to be in your podcast and I'm feeling excited. And how are you?

Lina Zubyte (01:06):
I'm good as well. So for our listeners, we're talking fairly early in the morning, so you may hear some sleepy voices. So could you shortly introduce yourself? What's your current job? Who are you apart from your work?

Aleksandra Kornecka (01:22):
Sure. Currently I'm the happy security engineer with solid quality assurance, engineering background and some other software development, consulting experiences. And that's most of my daytime. I used to be the semi professional light athlete, which means that I did some competition in sprinting and other quick running. And actually despite retiring as a sport person, regarding competition, I'm still doing trainings, so the functional ones in the stadium and the gym, and that helps to keep doing well at work and as a person. I love traveling. I like to experience the new places and food and people. And I'm also enjoying the nature, like hiking the forests or the sea or the mountains so that keeps me going as well. And apart from that, recently I am trying to improve my financial intelligence. I'm learning about investing: how to be smart about the money as for the future.

Lina Zubyte (02:31):
Wow, that sounds awesome. I really liked also that you mentioned that exercise makes you work better. Recently I was reading this book called "Burnout" and they were talking about stress and stressors and that stressors are things that happen in life and stress is something that we deal with in our body. And that first we have to deal with stress before we deal with stressors. So first we need to take care of ourselves, and very often it's actually movement that we need to exercise so that we feel better and then we can deal with whatever life gives us.

So I met you at the conferences that we used to go to and we were going to testing conferences. And your journey is very inspiring to me. So you used to be a QA and now you're a security engineer. What sparked you to change to security? What was the journey there?

Aleksandra Kornecka (03:29):
Actually, my interest in the security topic started already when I was a QA, of course. Not only in the conferences, but also in the day-to-day work. As I started quite close work on tasks and some threads with our security team in the company. And the guys were nice enough, and when I was digging and wanted to know more, they were happy to share, what they could, of course. And so as I knew already a little bit about security: what is it, what tasks are there - I found that, hmm, it's really interesting, maybe my next step, maybe also in the career. I felt a kind of a burnout with testing and QA topics because of the software development lifecycle, repeating issues or the people not always understanding the quality as a concept or as a need for the software. Despite being quite devoted to my job, I thought that maybe security could be this next step. And actually I really like to care about the security in private life as well, and I care about the people and it somehow resonated with my internal needs, let's say. It was multiple factors that brought me from QA to security engineering, but for sure the people and the reality played the role here.

Lina Zubyte (05:01):
It's really interesting that you also mentioned sometimes people not caring for quality and maybe heading into security is actually being an expert in that field and helping out people, not just with this advocacy or sometimes testing, but actually showing them things, what's happening. When it comes to security, we think of various things and very often we imagine, you know, hackers with the hoodies and pen testing and trying to break into the system. How would you describe security engineering?

Aleksandra Kornecka (05:38):
That's nearly the same challenge as describing the whole quality spectrum. Security engineering is of course a wide topic considering various areas. Let me maybe point some of them. So it's network security, application security, endpoint security, data security, identity and access management, kind of infrastructure and cloud security and security operations, and security governance, risk and compliance. Those are the very main areas. And actually I had an opportunity to work in each of them, maybe not let's say deep enough in each of them, but I touched all the topics.

So sometimes people think it's mainly pen testing or if I was a tester and, for sure, I need to be pen tester, but still I'm quite a poor pen tester and hacker. So that's not the case with the whole security engineering and actually that is really about touching all the software layers and beyond, as I said, infrastructure, the rules, the web application firewall, but it's also working still with the people about security awareness, the trainings, consulting internally for the product teams about the security. Explaining as well, as in quality assurance job, and yeah, looking for the security bugs sometimes as well, sometimes with the automated security scans. So just operating the tooling, putting the vulnerabilities found in the report and explaining them to the stakeholders.

Sometimes working on threat modeling with the teams and sometimes quite close to the privacy with privacy data officer or with corporate security. You cannot be bored there, but on the day-to-day tasks you are rather not hacking in the big company until you have the red team. So the ethical hackers team who are trying to either simulate or really do attacks on the company infrastructure or applications. But yeah, in our team we are more universal. So we don't have defined red/purple/blue teams. We are just working on what is needed currently. So definitely on the day-to-day jobs in the companies, it's not just to be a hacker, it's rather trying to understand the security of the company, the threats for them, and translating them to business language for the people. So that we all can cooperate on security,

Lina Zubyte (08:22):
I think that a lot of companies say that security is important to them, but maybe they don't even normally properly understand it. So you are now in that field for a little while. What are some of the most surprising learnings you've had about security after actually getting to work with it more?

Aleksandra Kornecka (08:43):
The thing that's really shocked me is that actually in the company this big enough to have some infrastructure and the reasons to be targeted, the DDOS attacks are happening all the time, literally each day. And it's not like, whoa, we have the attack. Whoa, it's like once a month or so. No, it's, it's like on constant manner. I mean the DDoS: distributed, denial of service attack attempt. In security operations, in monitoring you can see the spikes of the traffic, the malicious IPs that are changing all the time. So it's hard to spot them or you need to be smarter than these guys, and, and look for other ways to mitigate this traffic. So the biggest thing that was shocking for me, that attacks are really happening all the time. So you need to be careful, like on daily manner and monitor the situation. And now as an on-call engineer, I see also a lot of these things. Not always I need to react myself because we have a nice self-healing infrastructure mechanisms but I should at least monitor and in case something is too big in the traffic, I need to jump in and team up with my team and solve the problem.

Lina Zubyte (10:08):
What are some of the self-healing mechanisms that you have?

Aleksandra Kornecka (10:12):
So mainly just scaling the infrastructure because we are in the cloud, so we don't need to buy the physical server and be quick physically. It is just about the cost of scaled infrastructure and I think we have also a nice deal with the vendor. So it's not that painful. But for sure sometimes it's the vector of attack is even not to break infrastructure itself, but to put the costs into such a big amount that it'll be hard for the company.

Lina Zubyte (10:49):
That's really interesting, but also a common challenge that lots of companies have. And if we're not careful, we may actually pay a lot for not taking any measures when it comes to security. I've seen a lot of attacks actually in my career as well. And even recently this week there were some kind of attacks happening on our infrastructure. What surprised me a little bit was engineering team or the infrastructure/platform team, they were not shocked. They were like, it's okay, no need to panic. It happens all the time, and it happened again. So I think that was some kind of nice to see that and also normalizing it that this actually happens and you should be aware that it happens. It's not like it's something new.

Aleksandra Kornecka (11:37):
Do not panic, but yeah, for sure it would be nice if they also could say to you and to other stakeholders in the company: how to behave, why to keep calm and what report, right? So that's also this part of security awareness training that people know that even something is really bad, it should not be panic in the first place, but what to do and the steps. So that's a good opportunity also to learn.

Lina Zubyte (12:05):
I like that. Yes, we should be more aware that bad things do happen and what should we do in that case? One example that I can think of is when I would work very closely with monitoring tools and we noticed that there was one increase of traffic in one of our websites. When I was digging deeper, I saw that there was actually the same IP and the same browser hitting. I expected that it would be some kind of a bot like a spider browser, something like that. But it wasn't. The most surprising factor was that it was IE11 then. And I was like, what kind of hacker uses IE11? Are you serious? And after checking the country, we saw that it's actually India. There's one IP, one browser and we decided to just block that IP. That was suspicious activity. We did not know what's happening.

After a while, this website actually writes to us and says: "Hey, we did not tell you, but we decided to do, uh, stress testing on your environment. This is why we hired this company in India who were just clicking at the same time trying to see if they will put the system down and now they cannot see it anymore. How come?"

And it was a funny example for us when it comes to misunderstanding of what stress testing is and they tried to simulate it manually. So what are some of the misconceptions that you can see when it comes to security?

Aleksandra Kornecka (13:49):
Well, it was a perfect case to see how it could go. So the first rule to rule them all is that we need to separate production data and environment from the testing and despite how we said hackers, non-ethical security researchers, are often exploiting the vulnerabilities in the wild, in production systems. But it's not how we do normally. So, security engineers need to work on the stable pre-prod environment that shouldn't be maybe development, right? Which is unstable, but something in between. So last best environment before production which has a production setup configuration, but no production data. And there you can do the test like stress testing, maybe it's not typically security test, but also corresponds here because of the denial of service possibility. So that all should happen not in production environment because of these things like in your story.

People were just confused, it's the danger for the whole business to do the things in production because you never know if the test will be successful or not. So both stress testing and security test assessments should be done and not in production. Best way in the preproduction environment configured like production. So that could be one of misconceptions like where the security engineers are working and in what way.

So that also... it's about the pen tests. So security testing and taking the security seriously doesn't mean just to buy the pen test from some company or hire one pen tester or even a bunch of pen testers because in the company we need to take care of security from the scratch and from the people approaches, from strengthening our human firewall, let's say, together with hardening the security of other assets of infrastructure and our SDLC to make it secure SDLC.

So that's other thing that maybe we don't need like the whole army of security engineers. But for sure the persons have the variety of experiences and hands on experience not only in pen testing and it's a matter of avoiding the cost and also investing in the future, let's say better company state of security and state of the business. Actually security sometimes seems to be approached as a similar cost as the quality assurance activities, but in fact it's rather to securing the business as well, not only the software and the potential breaches or reputation damage so that cost could become investment for sure.

Lina Zubyte (17:14):
I really like this parallel actually the mindset and even mention of the human firewall that made me think of one episode in Mr. Robot, it's TV series by the way. And they were trying to get into unbreakable facility to steal some data and the facility was called the steel mountain and the whole idea of it was that it was unbreakable. That in itself makes me think of the Titanic effect: that when we think that the disaster is impossible, it actually actually is possible. So Titanic was unsinkable ship, right? So what wrong could happen? What could a little iceberg do? And when the crew showed the picture of the steel mountain to the main character Elliot, he looked at the picture and he was like, okay, like what's the problem here? And then they said, well there's no way, there're no security flaws here. And Elliot answered, well, I see at least two walking around here because there were two people in the picture. So what they did is actually social engineering, the human firewall was damaged and they did break into it. So when it comes to security, it's so much more than just this one pen test that you do for some kind of maybe even circus once per year, right? So we are so secure. That's like a show, right? That's a software development theater that we're trying to do. It's so much more. So what are some of the areas that many companies actually get wrong when it comes to security in your opinion?

Aleksandra Kornecka (18:57):
Oh my god, that could be a lot. So, I had the opportunity to consult for quite a big, growing but small in size startup. They wanted to be secured, but they had like little to no knowledge about security. So they started wanting me to do the pen test. So I was working with their tester and it was really great people and a nice startup, but the security was just in the paper, I think.

They had some firewall, but it was somehow outsourced. The developers were just hired to be seniors, so they just thought that they know about security because they're seniors, but no one I think checked their knowledge in this stage. So, I think there are lots of companies like that. Their approach is to hyper grow and make a profitable business without taking care of something happening before it happens. So it shouldn't be the diss for this company because it's just the reality.

So here we have the zero stage, right? People know that security exists, that they could potentially be targeted with some attack, but they think they're not yet in the stage where they should invest more. So at least it was nice that I was able to have some hours with them and I made a training about the security software in general, of course some social engineering as well, topics, how it can go or about tailgating and so on. So that is the basic stuff. Many companies in the first phases of growth are just either not caring or are caring, but having not enough knowledge or know-how: how to do security or where to start or what is really essential. And then we have the middle size that I haven't worked so much yet, but then we have the big companies like corporations.

And then I think, there is a just big, big, big thing about knowing the areas of security and to where it is enough to have one person of security engineering or what specialty this person should have, or how big team we should maintain to be really secure and still not to hire too much. I think that it's the time when it's good to be the universal security engineer because not so many companies, even the big ones want to hire the whole bunch like 100 people team of security even if they should which is coming from benchmarks for the size of the security team. So yeah, for sure it is challenging to know what size of your security team should be, if you don't have enough knowledge and know how in the company. And what specialty you need to cover all the topics that are already really important to you. But for that, security engineers are either doing or assisting in threat modeling risk assessment for either whole company or particular teams. So that's all doable. It is just a matter of knowing that it might be needed and doing that.

Lina Zubyte (22:44):
Yeah, I guess threat modeling sessions also can help us learn about the gaps of security knowledge. So if you had a little bit to give an introduction to threat modeling: what is it? How can teams do it?

Aleksandra Kornecka (22:59):
Sure. So that could be the first step because it's just about knowing your assets, how they're connected, what the flows of data are between them. There is no like universal recipe for each threat modeling session, but there is for sure the sketch, the structure.

First, most important step is to know your software. So what application services we have, how they are talking to each other, what are the integration parts like if there's an API, what kind of, or there is another way they communicate with each other, how the data and what data can be classified there and how they flow between the parts. So that's like reviewing the architecture actually of your software and the business flows and the identity of data there because other measures are for PII data, the sensitive data and a little bit other parameters of security could be applied to non-sensitive data.

But still the first is like architecture assessment, knowing the diagram of flows and then there are various standards and models like MITRE ATT&CK® of tactics and possibilities per type of software. Then you can use to assess what risks are really possible and how much impactful for you. So that's kind of assessing the risk for the diagram of software we have. And then putting testing scenarios, so attack scenarios, all this, the things that can happen that should be written down and analyzed. What is the probability of them happening? What are the most critical flows and assets that we want to harden and secure first? Because probably it's not possible to secure everything. So we just need to firstly know what is most important for us and then know how to best secure these things. And when we have the money and people work still available afterwards, we can think about the rest of the things. And when we already know that, what and how and the risk level, then we should cooperate, communicate with stakeholders: show this report of risk assessment and data and software flows and schedule the work on that.

And actually threat modeling should be conducted for each new service. In the ideal world. And in less ideal world it's good if you do the reviews at the least annually for what you already have. And also please do not omit the legacy code. I know that it's hard to assess sometimes even after the years of having legacy, but still when you're adding some new parts to that or even if never it was done for the legacy, that's still good to at least try to cover part of that. That's very helpful exercise not only about security engineers, but that should actually engage the engineering team, the product team, architecture review and security engineers.

Lina Zubyte (26:36):
I have seen some of threat modeling sessions where the whole team sits down and tries to brainstorm. There's one project I've seen on GitHub that's also free so anyone can use it. It's called Elevation of Privilege, where they basically help out to come up with the ideas of what attacks could be because as you nicely put, even when a developer is senior or we somehow assume and expect them to know everything about security, very often we may see as well in those sessions that people have no idea what could happen. And all kinds of cards are very helpful and they can understand as well what we know about the system and brainstorm and think, okay, what would I do if I was trying to break in there? What is the weak spot here? It's definitely I would say a team activity.

One other area that I see very often done poorly is logging. That for me is like the main sign of security gone wrong. For example, as a QA, I may check the logs out, then I check out the logs for production and I see personal data and I feel bad. I feel so bad. I feel like I wouldn't want to be in production systems' logs, I wouldn't want my email to be there, my address, my full name. What are some of your tips on how to make logging better in the companies?

Aleksandra Kornecka (28:04):
Oh, that's a huge challenge which is even bigger when the company size is bigger. So for sure your example with sensitive data in logs is a perfect example. That should be avoided, but really happens sometimes. Yeah, how to have good logging? So the best thing is to know what do you really need to log from what system services, but that's actually part of the job of the engineering teams which can cooperate with security team of course of that. But normally security team is just a team of less people than the whole company, than engineering teams. So they need to cooperate. They cannot inspect each one products team or engineering part by themselves like manually until they have some special application for that or some system. So the best thing is probably to raise awareness, to put the security training or announcement how the logging best practices are.

And there's a rule to log the most critical events with the most important parameters. But to assess which ones exactly, then I would probably need to know the structure of the system or what the critical assets are and yeah, the other things about the particular company, but the main rule of logging and the goal is actually to be able to detect the anomalies is right and potential threats and attacks. So, we need to ask each other what will make this goal happen to what are the conditions to meet this goal and later to check maybe if we have something which we are not using, which we are logging and it takes our logging possibilities or make the costs very big or that we have enough visualization of logging that we already can monitor important things. And the other thing is how quickly, how efficiently we can look over the logs, how quickly we can find a particular parameter or how quickly we can find the information. So there are many rules, but the specific of logging and what will be the best logging for my company or myself that's already to be assessed with the specifics of the company.

Lina Zubyte (30:50):
It's about having some kind of guidelines or standards, right, that all the teams could follow.

Aleksandra Kornecka (30:56):
Yeah, that for sure would be helpful. And when to put it into the training or even some company-wide assessment announcement or could be also that you put the best standards for logging to the company, you communicate it and later when someone needs or some team is not sure what to do, they can go to you as security engineer and it's just you can work together. So that's for sure doable, just need to have some set of basic rules and then dig into particular situations.

Lina Zubyte (31:35):
Yeah, that is one part of security awareness. When I think about security awareness, very often I realize that when it's security done well, it's invisible. It's same as quality done well, and I would say quality is like umbrella term. Also security should be a part of that. And when it's done bad, it's obvious and then we're like, why didn't we invest? Why didn't we do things? How can we actually raise awareness of importance of security? How would we even prove that it's worthy without first facing a disaster?

Aleksandra Kornecka (32:11):
Yeah, that's a little bit hard part because it all depends on the people which we have around. But the main rule is that it depends what company leadership is thinking. If it is the priority for them to have the secure business or they have totally another understanding or thinking. We have two situations possible. Either the people, let's say the individual contributors have the bottom up desire for security, they understand the need for that and they are just doing their jobs and communicating that it is important. Or we have the leadership or the CEO or, or just another senior leadership managers who take care of security, let's say the top down approach. And the very ideal word is when we have goods senior or just security aware and security practicing development teams and other in the company and also the leadership, understanding security matters and can be quite important in some points of time or even crucial.

So, that's the hard and easy part. The same time because it is on people, right? We cannot do enough good security in the company, which is totally against, they need to learn probably and see some really touchable examples of similar companies to them or to see the case studies for the big failures or attacks. But you cannot teach someone who doesn't want to be taught, right? It's really hard to put it there when it's not wanted, let's say. But if I should do something, then probably I'd use the case studies of the companies that are similar as the company that I approach. Of course I cannot do a pen test or do the attack to them, it's against the law and so on. But we can always offer the security tests in preproduction to showcase what can happen. Also there are just standards and compliance measures that are required to have some star, let's say like Michelin stars for restaurants, right?

Then we have the standards and certifications for the companies. So part of ISO or the audits can be security counters in place or some level of security. And that is actually the good thing. In European Union, we have quite a lot of them to be met if we want to do the particular business activity. So if not the understanding then we have the law that can help us to secure the business. So there are some ways, but for sure to have a really secure and securing people and software company, then it's good to have this understanding what it actually is and why it matters for business, not just for security.

Lina Zubyte (35:30):
What resources would you recommend for someone to start learning more about security?

Aleksandra Kornecka (35:36):
One foundational thing is OWASP project. It's open web application security project, which is actually open to everyone for free. Let's say, open source resources in writing and testing exercises. That's like the first thing that everyone could see. Also that's really great because despite that it's open source product, it's kind of a standard for most of the companies and there's nothing much better because it is about how to test your software and also a little bit organization and what vurnelabilities are there. And they also develop the cheat sheets to secure coding. So actually if you don't have enough money and resources, you can just point your people there and it's all in English and written in a very approaching language. So everyone can have at least a glimpse and develop the knowledge. Also there are many companies that are offering the artifacts for learning for free. Recently there is the action from ISC Square organization where you have the free certificate learning for certified in cybersecurity certification, and that's also more than just certificate because you have the security principles training inside and the very basics of authentication, authorization layers and as well the network security and system security topics.

So actually there is loads on of loads of free knowledge in the internet. Also some books there, even if you do not know anything about security today, you have enough resources to learn at least to the semi junior, let's say, and learning level. And of course later you can get the certificates. There are also a lot, but in fact you have the starting point then with OWASP and later you probably will learn the namings, the notions of the security and it will be easier for you to learn more and discover on your own the variety over internet and books.

Lina Zubyte (38:02):
Nice. I think it's a great message to start somewhere and sure, we just keep on reading and learning and tomorrow is a new day. So to wrap up the conversation and topics we've touched on here, what is the one piece of advice you would give for building high-quality products and teams?

Aleksandra Kornecka (38:23):
That's a really great question and the hard one at the same time. There is of course many factors, but I will try to give something concrete. So for me it's apart from the whole experience and learning, I think it's about communication. That you should listen to each other, to stakeholders and best if stakeholders are listening to you as well and understanding the common goal that we all want to build a nice business or to have the profits but secure profit, right? And to have some fun at work, but also to do the job. High-quality products and teams are also secure, so we should all care about it in our parts, let's say, because everyone's job should be secure itself. So as a security engineer, I can learn about your role and I can help your role to be most secure as possible. And you can also learn from your other colleagues from other roles. And we all can make this human firewall together and having fun at work and still be secure and profitable.

Lina Zubyte (39:44):
Wonderful. Thank you so much for this great conversation, Aleksandra.

Aleksandra Kornecka (39:49):
Thank you very, very much as well. That was great.

Lina Zubyte (39:52):
That's it for today's episode. Thank you so much for listening. I really hope it helped you learn more things about security and its importance. So until the next time, do not forget to keep on working and caring about those high quality products and teams. Bye.