[01:52] The ModSecurity Handbook

Rachael: Welcome to the podcast, Christian Folini. He is the co-lead of the OWASP ModSecurity Core Rule Set Project. He’s an author of the second edition of the ModSecurity Handbook and one of the few teachers on this subject. Hello, Christian. 

Christian: Thank you for having me, Rachael and Eric.

Eric: You're coming in from Switzerland right now?

Christian: Yes, absolutely. I'm Swiss.

Rachael: Christian, we talked a little bit about your background. I suggest everyone go to Christian's Twitter feed right now and see what he made this weekend.

Eric: Christian Folini, I can appreciate a good tomato like many.

Rachael: I thought he was a chef, I didn't think he was actually an IT. I was wrong. But I love your journey, you're 20 years in IT. You have a Ph.D. in medieval history, which I think is fascinating. I think of this in a recent podcast. It's not that different of a journey for a lot of people in it. How did it happen for you?

Christian: I wasn't quite sure if I was going to study computer science, security perhaps, or history. IT people pretty much said, no, history is not a secondary brand for you. Do Math, do Physics, but let's concentrate on this building here. The history guys we're much more open. Whatever you do, make it as far away as possible.

This gives you a background that adds something. You'll make an interesting individual person who can contribute to our branch with their second branch. That's how I take this. 

 

Medieval History

Christian: Then as it happens, when you continue studies and view medieval history, you make a Ph.D. in medieval. At last, you have to quit university or you'll die there, then it's easier to find a job in IT than it happens in medieval history. I actually applied for an open-air museum as a media relations contact. They didn't pick me and I was so pissed. I immediately went to be a system administrator.

Eric: That'll show them.

Christian: They're still disappointed by their mistake.

Eric: Turn their turn styles off or something.

Rachael: Was your dissertation around medieval monasteries? I think there were some really interesting parallels to what you do today.

Eric: I just want to point out to our listeners, the Comp Sci program said, "No. You need to stay in this relative discipline, math or science or something like that." The medieval history team said, "Get as far away from history as you can because we want you to open up your mind and look at parallels." Which Rachael's question is really about. We want you to open your mind.

I feel like in cyber security, that's what we want. We want people from all disciplines to open their minds, they make us better. It's so disappointing. A Comp Sci program, not all of them of course, would say effectively, “I guess what they're saying is we want you to go deeper, not broad.”

Christian: Yes, perhaps.

Eric: I wanted to make sure I understood that. We have a lot of people from different disciplines who are either in cybersecurity or want to get into cybersecurity. They don't feel they can because they don't have a Comp Sci degree. And they don't have a degree in mathematics or cryptology, that's not required. 

 

Medieval Monasteries and the Parallels to ModSecurity

Rachael: I think your dissertation was on the study of medieval monasteries. What you were describing and the parallels to IT are really fascinating. I'd love for you to share that with our listeners.

Christian: I branched out university and specialized in medieval history and then I came back into IT. I was with IT before I studied it. Now, I'm bringing that background into IT. They hate how good I went so far away because now I can really contribute. 

Once I realized how a medieval monastery is organized, you basically have the outside world, that's the internet. Then you have a wall around it. You have the inside world that's your enterprise with your assets. Then you need to have an exchange between the two worlds because people will starve inside without that. 

So they need to bring their food or people come to the monastery to make donations to offer them money. They pray for them, they have services to offer, and then, "This topology that actually resembles an internet, a web server with a firewall around it." An application. Then you have payloads. Yes, there are a lot of parallels around this. what struck me was a Ph.D. and I made a section about that. How do they regulate this? 

Back in the day, you had regulation, how do we run our monasteries? It's all written text, you have to do it as follows. The part in that regulation is the biggest amount of space in the regulation is the interface, the definition. How do the inside talk to the outside world and the other way around? Like today if you do threat modeling, what is the most important thing? It's always the interface. 

 

People in IT Security

Christian: I thought that was really striking. It took quite a long time for me in IT security to realize how much my education actually contributes to that. There are so many people in IT, also in IT security. They have this imposter syndrome where they sit around, "I must be the only one with a history degree in this room." But actually, it's quite a lot of people. A lot of people have marketing degrees and stuff, but very few IT security.

Eric: I feel like that was a dig. We'll leave the marketers out of the equation for a minute. For our listeners, my undergrad is in marketing. Christian, you'll be very impressed. It's a Bachelor of Science in Marketing, meaning it was very data-driven.

Christian: It is a Science.

Eric: One of the few out there. I should have gone to medieval history.

Christian: I'll tell you it's the best thing.

Rachael: I love that you're part of this company of St. George too and working with museums and reenacting events. Can you share a little more with our listeners and then we'll talk about OWASP?

Christian: We're a living history or medieval enactment company. We go to castles and make a display of medieval history for the visitors within the castle and we demonstrate stuff. Also, we do artisans, a bit of military, and a bit of medieval gunnery. Then, once the visitors leave, we get to have the castle for ourselves.

So it's a win-win for everybody in the end. It's a lot of fun. I tried to make a living out of this defending medieval castles, but then defending web servers was easier to be paid for. That's how I ended up.

Rachael: Probably more lucrative too.

 

[10:00] Civil War Reenactments

Christian: Yes, and less risky.

Rachael: I would love to see photos of all the medieval items. In Texas, the only thing I've been exposed to is the Civil War reenactments. I knew someone that had a cannon of course. That's really why they went. They could see the cannon go boom and that was it.

Christian: Guns are really cool when they go boom.

Eric: I haven't had a chance to think about this, but you're comparing the castle walls, which we've talked about a lot. The monastery walls, I guess probably a better description of firewalls from a security perspective. You always hear about it, the castle walls.

As we move to the cloud and we talk inside our thread and different components of cybersecurity, the old castle wall moat concept doesn't necessarily apply. Have we seen over time, I'm going back to your history background here, where walls don't necessarily apply as we move to the cloud? It doesn't necessarily apply. Have we seen parallels there also?

I've never thought about it. As society evolved, did it evolve somewhere? I guess we moved out of castles eventually as society developed and matured. Is there a parallel there? I was going to say fragmentation, but really it's the democratization of it as things are going to the cloud and they're going everywhere.

Christian: I might challenge the perception that we are run without these walls in the cloud. I think people think they run without a wall or they can run without a wall around without a firewall until they realize nobody's protecting them. That is because they forgot about the web application firewall. The firewall itself, I actually keyed about these topics. Are there parallels between building casts and building server defenses? 

 

Physical Security Versus ModSecurity

Christian: I think when we defend web servers or servers in general, this is a fairly young discipline meeting. We've been doing this for 30, 40, maybe 50 years, but they have been building castles for thousands of years. We really know how to do physical security, but we're not very good at digital security, online security, or cloud security.

What I think is really useful in what it boils down to is a multiple-layers approach. This can be OC layers and it can be in the cloud. It can be a fabrication firewall, but you need to have multiple security layers. If it's input validation, then that's great.

If you ever want to do something, you want to monitor your application as well. Maybe you want to sandbox something. That's all different tools that give you security and they complement each other. I think that's a history lesson that works. Putting all your racks in the same basket doesn't work. I guess that's also applying to the cloud.

Eric: The cloud is a different platform but the concepts are similar in many ways. They're different but similar. 

Rachael: I would love to talk more about ModSecurity, but if you could share with folks the OWASP project, what you guys are doing there? It's a really important mission.

Christian: We still have time for that, but it's a big, big box. We run a web application firewall rules project. The web application firewall as compared to the network firewall runs on the application traffic. It really inspects the HTTP payloads. This is championed by the PCI-DSS standards, the payment card industry standards where you have to have this. This is how this fabrication firewall industry was started like 15, 20 years ago. 

 

An Engine Called ModSecurity

Christian: There is a thing, an engine called ModSecurity, which is the dominant player and it's an open source player. This ModSecurity, the engine has been driving this. There are lots and lots of commercial projects, but half of them are based on this open-source engine. It's a commercial integration of an open-source project but this engine doesn't give you security by itself, it's just the engine. The interesting part is the rules that you implement on top. People talk about

ModSecurity, but what they really mean usually is the rules, not the engine.The engine is a commodity, it's just like a Linux Kernel. It's not so interesting anymore these days. So you need rules on top and I'm one of the leaders of the standard rules project which has a very lengthy name. It's the OWASP ModSecurity

Rules Project. OWASP is an umbrella project or a foundation, the Open Web Application Security Project. We are one of the flagship projects. We’re sitting next to OWASP or the OWASP top 10 security risks that everybody knows. 
We light on that level one of these many projects, we focus on this ModSecurity engine, and we develop rules that you then run on your servers. A lot of people have run this natively.

I would say certainly more than half, maybe two third of the commercial web application firewall market is using our Apache license rules on their commercial products.

All the big content delivery networks, the cloud, and the web application firewalls in the cloud, have CRS Corals set offering by now. When you go to one of these and you check box the security option, give me a web application firewall, this is what they usually get. They make their own selection of rules. 

 

Native ModSecurity

Christian: We like the base and they pick what they want to use, but we're the base project. We're there are a few alternatives. As a leader, I would say there's no alternative to our open-source product. Either your commercial company does this from scratch yourself, which is really hard and expensive, or reuse our open-source stuff. 

What most people do, I think, are only the big, very expensive banking-level web application firewalls. They have their own rules at their own engines. The rest of the market probably uses our rules sometimes on native ModSecurity or they have long replaced the commodity engine with their own replacement because they like the rules but they don't like the engine so much.

Eric: But you're saying a bank would actually create their own engine?

Christian: No, they buy a commercial product.

Eric: They buy a commercial product and use their own custom rules.

Christian: All commercial product comes with their own rules, their own engine. It's a different breed, but I think that only exists and continues to exist in the top-tier market.

Rachael: If I was reading correctly, there was a CRS 4.0 release?

Christian: Yes.

Rachael: What's different there? I think I saw something about a bug bounty as well.

Christian: There went in the full clash together, the 4.0 release and the bug bounty. We're a standard open-source project. We did a major release of 3.0. When we took over the project, it was dormant. We revived in 2016, made a big release, and then we did an incremental release ever since. Now we were heading towards 4.0. 

 

Big Buck Bounty Program

Christian: We released a first release candidate, if you will, in spring at the same time with all the new features, and all the cool staff who wanted to present to the world. At the same time, a very large user, a big integrator approached us and say, "Look, we have a Big Buck Bounty program. We would like to host a CRS and OWASP CRS Buck Bounty in our platform, we pay all the bills and the bounties, but you fixed the rules afterward".

And we say, "Cool that's such a great idea, let's do this. Let's go head down, let's do this." Then we got over a hundred findings. I guess that's what always happens when you bump into a Buck Bounty program. We thought about this, we prepared this, but then the program really kicked off and they supported each other, lots of hackers. It's a private program where hackers started to talk to one another. 

"Have you seen this? Maybe we can dig into that." Then it piled up and we were stunned. It simply destroyed our release set plan for 4.0. because we cannot 18:55 for the good. The resulting 4.0 will be much stronger because of that, but it will be delayed apparently. So we welcome this but it's a lot of work.

Rachael: How do you prioritize? Knocking down, I mean a hundred is crazy. How do you even attack something like that?

Christian: I wish I had an answer. What we did, was first stun and then we tried to group them by severity. Then we had a few ones really critical, whatever that means, and relatively low. 

 

[19:39] A Very Sophisticated ModSecurity

Christian: Conceptually, when you have a web application firewall, you can never detect everything that doesn't work. You just blatant the text, please protect them. It’s very sneaky, very sophisticated stuff. Maybe slow it down, maybe make them really hard. 

But we couldn't stop the NSA from targeting a standard server. It's conceptually not really possible with that tool having a bypass, somebody sneaking around our default installation. We have different levels of security which is a standard business. We‘ve discovered, let's fix this, let's move on. But then there is a higher security bypass. We say, "If you go to top security and they still bypass the rules, then we really have a problem".

So we try to group that and then we realize we're really losing the overview here or it's hard to keep an overview. When we talk about what is integrated before they launch a program, we tell them we probably have a capacity of two or three findings per week. If we do a hundred a year, then that's a lot. two dozen per week doesn't sound like a lot, but it pans up to a hundred. 

A hundred is substantial for a volunteer-driven open source project. We all have our families in day jobs. We got over a hundred and said, "This is one year of work in front of our eyes now and what are you going to do now?" Then we were in a good position. We have a bit of fund, so we could pay one of our developers to work for a couple of weeks. He would standardize all the findings into curl requests.

 

The Attacking Payload

Christian: Curl is to a common line HTTP client where you do a curl call with the attacking payload and then now we have a hundred current calls that we should block. That is a lot easier than reading up a hundred submissions because he has done the translation work.

Then from the current call, of course, we can do the test run because we do uni testing. Say, "This current call has to be blocked." With the current call in our hands, we have a script that does the test for us in the special jam-chasing format. 
We're getting closer to the solution.

What we're doing now over the hill, now, we solve two third of them. For the remaining ones we have to test, all we need to do is to define the pattern to detect it. Usually, we have an existing rule that should in concept detect this, but the rule has to be expanded.

These rules are regular expressions. They're really hard to read but once you get to hang of it, it's doable. It's just a question of work and a bit of experience because, with every detection we do, there is a risk of a false positive. 
We might block somebody trying to do a bank transfer to somebody with a funny address, then it's flagged as an SQL injection only because that person happens to live on Union Street. 25 Union Street and Union Street could be an ESCAL statement or part of an ESCAL statement. So if the rule is stupid, it would flag that as an ESCAL attack.

This is how this world community pays really attention to that. It takes a lot of testing and a lot of discussions apparently. 

 

Potential Vulnerabilities

Christian: If you rush into this, then you may destroy more things than you fix. It's not as quick.

Eric: I don't know what you did here but you get these a hundred and some findings. Obviously, they impact current customers, in some cases. They were 4.0 findings. But if somebody was using three X or below, the findings could still be valid. How did you process and think about notifying the world, the constituency, "We have some potential findings or vulnerabilities? We're working to fix them." What'd you there?

Christian: There are multiple channels here. We announce this to the big integrators. We got in touch with them. Once we have established relationships, we reach out to them. Sometimes they respond, and sometimes they don't. But by now we have a broken relationship, like most of them. And then we did one or two block posts.

People say, "Look, this is what's happening." Of course, we cannot do a single big poll request. It's fixed tomorrow. This is a rolling update somehow. I know that a couple of users, they're following the development branch, and then they see the new tests being added. 

They see the rule fixes so they try to run on the latest edition of the rules. But in all honesty, for a lot of people, it doesn't matter so much because they realize the valve is only one of our security components. We have additional layers of security and just go with the latest release. The CRS guys will do a new release, one and a half to update, so the mileage really varies. I would personally say people could pay a bit more attention. 

 

Changing Rules

Christian: When we did the block post, we got surprisingly little feedback. On the other hand, when Log4J came out last winter, we followed up immediately with updating block posts. We explained our reasoning and what rule, and how we changed the rules to fix all the bypasses. There was a lot of feedback.

"This is great." We went to production immediately because we saw this Log4J for your rules. This also opened doors with integrators because they relied on this stuff and say, "What you're doing is really solving problems for our customers." That builds a lot of goodwill with integrators for us.

Eric: Was anybody internally arguing, "We've got to keep this quiet until we fix everything." Say nothing?

Christian: Not in our project.

Eric: So in your group, it was really, we've got to let the world know this is open source. We've got to let them know so they know what the vulnerabilities are. They know what they need to deal with on their side while we go back and jam on the hundred and some findings.

Christian: If it's one or two big findings and we have had this before, then it's a CVE and we coordinate everything. But here, it's just too much. We have to keep afloat by fixing as we move along. We're more or less keeping people updated. All of them are done now. Two third of them are done. We hope to bring out 4.0 later this year. Maybe it's going to be winter. It depends. Also one or two things, we are really an open source project without a company behind it. 

 

Buck Bounty Hunters

Christian: We're just a group of people working together and nobody has an interest here in keeping this a secret. In the end, you cannot keep it a secret. It's contributing Buck Bounty hunters. They can release it any day they want.

There are different levels of sharing with the community. We're sharing more with our sponsors apparently in a conversation with them. How would you fix that? Or they ask us, can we do something about this before you have a fix? Is there a workaround right now? Stuff like that.

Rachael: It's a volunteer group doing all of this amazing work.

Christian: But honestly, you have a weekly rhythm. This is a commitment. We're going to have a project chat tonight. It's going to be two hours, probably, and we're going to talk about issues. Who has a solution for this issue? Somebody has proposed a solution, but you guys think about this. I think the other guy who's not in the chat tonight should reach out to him because he had ideas. Somebody remembered that. 

It's just project work. What is good, we have a dozen of developers, a good group of people, very diverse background group of people. That really helps. They come from all sorts of life and they contribute to this common goal. It's an interesting project and it's good fun. Some of them work with that and some of them do not.

Eric: Why do they do that? What brings all of you together on this cause, this crusade you're on?

Christian: If I start from myself, I used to be a contractor consultant and security consultant. I specialize in ModSecurity in this engine and then the rule writing. 

 

[28:18] Is ModSecurity Difficult to Understand?

Christian: My reasoning was, "This is really difficult to understand. I'm sure people hate this. That would be good to specialize in. People will want to have me as a consultant so they don't have to learn this themselves because I feel that's cool." I like this somehow, I don't hate it as much as everybody else. That's how I specialize in this. 

Then of course it makes sense at a given moment to drive this project. We have so much experience. I feel we're doing this for more than 15 years. Then we have one or two internet hosters and one of them says, "We are a security of our internet hosted. We do a lot of WordPress." WordPress has weaknesses all the time.

We're attacked every day and every rule that we can deploy saves me time. If I have to reinstall a server, that costs me a lot, my customers, and a lot of resources. I hate this. If I can work with other people to protect my servers with an additional layer in front that protects my WordPress installation. 

They have their own security team, but we have a safety net in front, then it supports me. Then we have somebody who's working for an integrator, somebody's just interested in the project. We have a female CSO, which I mentioned, we open this project with female volunteers in it. She's a CSO for a Swiss company.

We have a university dropout who has found weaknesses in our project. Once he added us to his own portfolio, he has a CVE on his name. He doesn't have a degree, but a CVE for a critical industry component, and he got a much better job out of this. 

 

Understanding the Engine

Christian: We're helping people here. This is really cool. Then we have a guy who's a C developer and thinks I'm contributing to your understanding of the engine. If we don't understand how this works, then I'm digging into resource code and tell you how it's working. We really complement each other from different backgrounds. Apparently, I'm the only medievalist in this group, so this is what I contribute.

Rachael: I was reading about Trustwave. They announced the end of support of its ModSecurity engine in 24. What does this mean?

Christian: Trustwave is the company and they own the engine. They did a merger or purchased the company 12 years ago and got ModSecurity on top together with that company and they used to develop it ever since. I cannot really tell you why they want to end their support in 2024, but they made this announcement. Then we reached out to them in business talks, and they made it clear they're not giving it away before 2024.

Afterward, somebody can pick it up and do whatever they want with it. Right now, anybody could fork it just nobody did so far. There are reasons for that. I think there is not really so much of a necessity because it basically works. There are alternative engines around.

Commercial integrators have their own engines already. There is a new kid on the block who wants to become a drop-in replacement.

So even if there is an end of support, somebody will pick it up, somebody might fork it or we're going to replace it with another commodity engine. The engine is not the interesting piece here, but somebody, so many people have replaced that already. It's about the rules. 

 

The Engine from Trustwave

Christian: The intelligence is in the rules and then you just need somebody to do something to run these rules. That has been done dozens of times before.

Eric: So for those who are running this, the engine from Trustwave, they're pretty aware of it. 

Christian: I guess. I've had people reaching out to me. I've seen people looking around looking at this. A new engine gets a lot of support because of this. Because people "Look, we want to go away from this more security base by between 34. Let's look into this thing now while we have time." Other people would just say, "Basic multi-security works and if it stops working, then we'll find a solution."

This is not such a big deal. I'd say this is an established product on an established web server like Apache. Multi security works best on Apache and that's pretty done software. These incremental updates, I think it's all a bit lazy here, but it's basically working. There's nothing to really fix, no urgency, no rush.

Rachael: Shifting gears, just reading your bio Christian. You do so many things. I would love to hear more about you being the program chair of the Swiss Cyber Storm Conference.

Christian: The brand is so cool, Swiss Cyber Storm. We're a national security conference. We're a one-day conference and it's national. You don't travel to Switzerland for a one-day conference. What we do is bring the industry together in Switzerland and bring international speakers. With the size of the conference and the money that we have, tickets are not really free. A couple of hundred bucks allows us to fly over people from the states for example. 

 

ModSecurity Superstars in Switzerland

Christian: We have a guy from Ethiopia presenting. We try to have diverse backgrounds. People are bringing in ideas. The superstars you can see in Switzerland every year, Bruce Schneider, Kevin, probably see them every one or two years in Switzerland but we're bringing people. We had Wendy Nather, as the keynote last year. I think she's not known for it, but she's such a great person. Everybody should know Wendy Nather. So let's bring her over.

Change pays a bit, bringing new ideas to the country. It’s always the same people presenting. The local speakers, it's always the same 20, 40 guys and women in Switzerland. We spice up because we have the funds, and we can bring in people on an international level. It's a diverse conference in the center. We have CSO security officers, security researchers, academic students, all penetration testers, and auditors. For one day, you can bring them together and get them to talk to one another. 

Rachael: That's a lot for one day.

Christian: If it's a longer conference, we specialize more. If it's an attack Defcon-style conference, you get a different breed of people. We try to level this and have something for everybody. The end of the talks is the inspiration to get a conversation going. People talk about this in the hallway track and then they return to their job. 

They say, "I've been to this conference yesterday, we should really look into this," because this is a new idea and we need to learn this. To give an example, buck bounties were really unknown in Switzerland for whatever reasons. But three years ago, there was a single Buck Bounty program on a national level in Switzerland and no bank data. It was a no-no.

 

Embracing the Hackers

Christian: We launched this in Switzerland by doing the motto and embracing the hackers. Telling them, "If you have an application security project and you're not doing a background, you rely a hundred percent on penetration testers, you are not really protected."

Because penetration testers are not able to find all the things that a Buck Bounty hunter might do, they complement each other. 

This could immediately last two years with all these programs popping up all over Switzerland. The government announced their big government-wide Buck Bounty now it was only two weeks ago. We kicked this off with a conference like that. A role in the country would say we try to set the agenda, bring in new ideas and get people talking about this. Sometimes it sparks something and sometimes people couldn't care less. That's okay.

Rachael: That's cyber.

Eric: This year, I believe it’s on the 25th of October. You're kicking it off. I'm just looking at it right now, but it's about digital identities and how to secure them. A focal point. A topic.

Christian: It's really around Christmas we take out a crystal ball and then we go the next autumn, “What's going to be a hard topic in Switzerland? What is ripe by then? The electronic identity.” It was a good guess because we have a law, an electronic identity that's being implemented right now. We already shut down a law last year. It's not surprising to bring in a new law. We guess by October this will be ready, this will be ripe for discussion and it's working out nicely. This is how we got up with that. 

 

[37:51] eHealth

Christian: In early January 2020, we scheduled eHealth as a focus topic and then the pandemic hit. But we were before the pandemic and then we had to cancel the conference. This was our pick, it was too good for the COVID-19 pandemic and we had to cancel that. That was really a pity. But we were spot on that.

Eric: We'll take our press badges, maybe do a show from the show.

Christian: Come on over. I have you at the speaker dinner Monday night.

Rachael: I would love that. I haven't been to Switzerland in ages. I used to work for Victorinox many years ago.

Christian: This Swiss company, Victorinox is the only Swiss company allowed to use the code of arms of Switzerland.

Rachael: Yes.

Eric: Not only did she drive 128 kilometers an hour on Texan roads, but at least she got caught there. She's got that Swiss connection.

Rachael: They were a very lovely family.

Christian: Darren is known to be a really nice company. 

Rachael: A lot of people worked there a long time, the second, and the third generation is working there too.

Eric: Predicting the future. We've got digital identities and how to secure them this year, what do you think about next year? What do you think is going to be hot over the next couple of years that people really care about?

Christian: Predicting the future is really difficult.

Eric: But you already did. You were just taking credit for eHealth. I'm going to pull on that string a little more.

Christian: It's hard to say. I think source code could be interesting or I think the human factor. As social engineering maybe, how do you get people to write secure code? 

 

A People Problem

Christian: This is a technology problem, it's a people problem. So how do you do that? How do you recruit good people in IT security? Everybody has that problem. How do you make them like your company? So they want to join it. I think the human factor, but it's teamwork and I cannot announce the 2023 model already here.

Eric: Just looking for a scoop on the big areas that are on your mind that need help. Digital identities, I think you nailed it. eHealth probably should have been a year early. Five years early, even better.

Christian: What we found out during the pandemic in Switzerland when they do the number statistics they do it via facts. Of course, it's facts. Who would need computers here? Maybe it wasn't overly early, it was bleeding edge. Let's talk about security in eHealth because they're only starting out and with the Monkeypox, it's still facts.

Eric: I think you'll need it going forward.

Christian: Thinking about Agile again, everybody's doing Agile now. When you collide with security because it's so agile, they postpone security. How can you secure something or keep it secure when you’re constantly revising your code? I think that would be an interesting question.

Eric: We're having shows on that.

Christian: I think it's really hard. I think it's a good topic to look at from a different perspective. We have to be talking about that problem from his perspective this year. If it catches on, people enjoy that speech, this presentation, then maybe we could do this in one of the following years. I think there is a lot of research going into that and a lot of thinking. 

 

An Exciting Future for ModSecurity

Christian: 5, 10 years ago Agile was super cool. Now people have a hangover from all this HR stuff and it's still not secure.

Rachael: This is an exciting future. We're never lacking in things to talk about or work on.

Christian: We're never out of work in security. 

Rachael: No, but I do love the point you made about the human factor, particularly recruiting and getting that next generation interested in security. I love that you're able to share your story. It doesn't matter how you get there and you don't need a degree to be successful.

Christian: We've been left the security end of the techies for 20, 40 years, and look where we are. It takes people with different backgrounds who understand this is a human problem. This is not a technology problem, it's a human problem.

Tech is not necessarily good with human problems. You need psychologists, history degrees, and philosophers to really think about the concepts behind it and why it works the way it does. Why do humans behave the way they do? How can we make secure computing with the humans we have because we're not going to replace them?

Eric: We just did a show a couple of weeks ago with Tony Sager of NSA. Tony was talking about wizards which I found fascinating. He's now with the Center for Internet Security here in DC He talked about these wizards and how in tech and cyber, everything's complex.

We want to keep it because we have the information and it's hard as opposed to opening it up and sharing with everybody and bringing everybody in. 

 

Specialist Generalist

Eric: You don't need specialists. Well, you do, don't get me wrong. You need specialists. But we need generalists, we need everybody to understand what's going on. We don't need to keep the keys to the kingdom with just a select few, which is the way it really was back in the early days.

Rachael: I think it's so interesting what comes out of sharing these problems and having diverse teams working on these problems. They're out-of-the-box solutions, then, that actually makes a lot of sense here.

Eric: I probably agree with you. We need people to solve people's problems. These problems were created by people, they will be fixed by people. To do that, you need a whole society view.

Rachael: I think to your point, Christian, there's a lot we could learn from history. Let's be honest, these attacks or misinformation or all of these different things that people are doing today, they're as old as time. They're just being executed in a different way. I think there's a lot that you can learn. Having a background such as yours is really fascinating.

Christian: I think this helps and is piling up on that. What you really learn when you study humanities is what you work with. Incomplete information or contradicting information, and incomplete sources. When you talk to techies, they go, "This is dangerous now." But when you go to the real world in the IT industry and this is what you get. Make the best out of it and then get really insecure.

One person manages this background, "This is what I learned." It's always been like that. It’s never a complete source. I've done medieval history, I've so much information. 

 

Humanity Skills

Christian: My lock file is so long, what can I make out of this? What conclusions can I do with so many locks? That is so helpful in IT security because it is used to gray cell to really draw your conclusions or a minimum of information or balance contradicting information. That's humanity skills, not love a techy skill.

Eric: That is such a great perspective, a great way to end the show.

Christian: It's like five hours, so I did an hour. I felt like I had to break it up, but then I got distracted and this other documentary. Anyway, that's a wonderful thing about online. You don't drive in these lessons.

Eric: Not for long. In the states, you have to. If you get a big speeding ticket, you can keep your license or lower your insurance or lower the cost.

Rachael: Christian, thank you so much for joining us. This has been such a fun conversation. Really appreciate your time and really love your perspective. I think it's important that more people hear that and it makes me very positive for what's ahead, for security as well.

Eric: October 25th, Swiss Cyber Storm. We've got a dinner date.

Christian: Yes. On Monday 24th with all the cool speakers.

Rachael: To all of our listeners, thanks again for joining us this week. As always, double-click that subscribe button because you get this episode right in your email inbox and so much more. Until next time, be safe.

 

About Our Guest

 

Christian Folini brings more than ten years of experience with ModSecurity configuration in high-security environments, DDoS defense, and threat modeling. He is the author of the second edition of the ModSecurity Handbook and one of the few teachers on this subject. He’s a Co-Lead of the OWASP ModSecurity Core Rule Set project. Christian serves as vice president of the Swiss federal public-private partnership "Swiss Cyber Experts" and the program chair of the "Swiss Cyber Storm" conference. He is also a frequent speaker at national and international conferences, where he tries to use his background in the humanities to explain hardcore technical topics to various audiences.