 So, coming up next, we have Incident Lifecycle and Incident Response Management Planning with, so sorry, Rahul Patel and Tanya Rice. So, I'll give them a quick introduction. Rahul Patel is a seasoned cyber and information security professional with over 25 years of experience defending the availability, confidentiality, and integrity of information assets. He is presently leading election information security and risk management efforts at the office of the Cook County Clerk and Chicago Board of Election Commissioner as Election Information Security Officer. Patel holds a PhD from North Central University, an MBA from DePaul University, an MS from Illinois Institute of Technology and, oops, sorry, and Tanya Rice was appointed director of elections by Cook County Clerk Karen A. Yarbra in 2019, in which capacity she supports operations for one of the largest election jurisdictions in the country. Rice began her career in elections in 2005 as a political science graduate student at the University of Michigan, where she was a National Science Foundation Graduate Research Fellow specializing in public opinion on voting technology and post-election audits, as well as the political participation of language minority citizens. Rice holds a JD from Northwestern University School of Law, an MBA from Northwestern University. Please welcome them. Thank you very much for the introduction and thank you to the DEF CON organizers and all the attendees present, and allowing us to share some best practices for local election officials, which we developed based on our professional experiences and review of expert literature on incident lifecycle and incident response management planning. So first I can share a little bit of background information about elections in Chicago and suburban Cook County, which are complex operations governed by two offices. The Cook County Clerk is the chief election authority for suburban Cook County, which consists of 126 municipalities. The Chicago Board of Election Commissioners oversees election administration for voters who reside in the city of Chicago. Both the jurisdictions have about 1.5 million registered voters, so the combined three million registered voters makes Cook County one of the largest jurisdictions in the country. Our offices have a team of IT professionals, but we are very fortunate to share a dedicated elections information security officer who helps strengthen our cybersecurity posture. So over the past few years, like most local election officials, we found that the volume, types and quality of cybersecurity attacks and elections have become more damaging and disruptive and new types of cybersecurity incidents have emerged. And the white paper we developed for DEF CON this year, we wanted to provide a holistic and practical resource for local election officials and the public to more readily understand incident response management planning. So we provide the overarching workflow for election security incident response. We describe point in line analysis, which is a methodology that considers several factors such as attack vectors, motives, probability and impact. And we also provide several templates or samples for incident response management, which local election officials can modify for their jurisdictions. So we begin our analysis with a general problem in election cybersecurity. A cyber incident can span a wide spectrum of malicious cyber activity. And for the elections environment, it can range from the fact of voter registration data to the disruption or manipulation of the vote tally. And this challenging environment, election officials and IT professionals must find effective ways to decrease response times, decrease recovery times and limit costs. So now Rahul will walk you through our technical approach and solutions. These methods can be modified by any local election office. Thanks, Tanya. So before we talk about the approach, let's learn the cycle of like how from start to finish what happens when the incident occurs, right? So at start, we have normal operation, everything works fine, right? And then something happens at that vertical line, right? Something bad happens. Then we start working on detecting that incident, right? We might have a manual process or automated process, some of the APT kind of issues that that detection takes months, right? Some issues they are more apparent and it might take a few minutes, few hours, but it takes time to detect an incident, right? Once we detect the incident, then we start working on troubleshooting what we need to do, what are the symptoms, what systems affected, how do we recover, we create some kind of planning, right? We don't at the start, we don't know what exactly the plan is, but at the end of that troubleshooting cycle, we have some idea of this is what I want to do, right? And this is how I'm going to fix the problem. Then the next stage is now we are going to start responding to it. Now we made a plan, now we are going to implement that plan, right? And at the end of that response cycle, depending on how much we need to do, there is some time that we are spending, now our response is success. At some point of time, then we are going to start recovering, right? Now there is a recover and restore, there are two steps that we are going to take. First, we are going to recover the system. At the end of the recovery, we can say that now that issue does not exist. System is back to normal and we can start using the system, but we haven't started using the system yet, right? From system perspective, we are back to normal, but we haven't started using it yet. Then we might have lost some data, there is a point of time, recovery time, right? We might load the information, we might test that what is happening is everything normal now, and then we start asking the user to start using it, or another system that is using the system that starts using it, right? Then this restore process starts. At the end of the restore process is when, let's say you have 1,000 users or a few systems using this subsystem, when we go up to that level of utilization, that's when you are back to normal, right? Until then, we are still recovering, we are still restoring, right? Now if you think about all these different stages, there are certain necessary waste and there are some productive steps, and I say necessary waste means it's necessary, right? Detection and the troubleshooting is necessary, otherwise you wouldn't be able to figure out what is the plan of action, right? But I say it is waste because we could do that before the incident can happen, right? If we know that what are the symptoms, if we can pre-detect that if there is a DDoS, for example, if there is a DDoS attack, what would be the symptoms, right? If I know that, I don't have to get into the DDoS before I start figuring out how am I going to detect, right? And what is my response? What is my plan for responding, recovering, restoring? I don't have to wait for that incident to happen. I can figure that out in advance, right? So part of this detect, part of this troubleshooting, right? That's necessary waste, but it doesn't have to be at this time. It can be done in advance. If you look carefully that what exactly are we doing in responding and recovering and restoring, there are some steps there that too, you could pre-plan before the incident happens and you will find some necessary waste in those areas as well. The idea is we are going to call up this to vertical line as much as possible, right? So we are not in that incident for a very long time, right? So how do we do that? For election, now this, this time, I want to go back, sorry, who is taking the pictures, but I want to go back to here. Now that there was an incident at Capital One, like a couple of weeks back, right? And you might have heard the news that the way they detected and the way they responded in some of the news, they have said that they did a very good job because the whole incident last only 10 days. Election is one day, right? So if we are running into this election, this kind of incident, we don't have a day, we don't have hours, we have only a few minutes to go from, from that to here, right? And there is a lot of expertise involved in many of this, in detection mechanism, in troubleshooting and responding and recovering, right? So we cannot do it alone. Yesterday who came to the speaker track here? I mean, there was common theme, the resources, right? So one organization cannot have expertise and enough resources. So we rely on a lot of different partners, federal partners, state, local, a lot of DHS folks are here. And, and private companies too. I met somebody from Cloudflare. So there are a lot of partners who offer the services to election administration, right? So working with those is very important. Find out where you can get the expertise and pre plan, pre plan, how are we going to detect the issue, how we are going to troubleshoot. And if we have, if we can pre stage some of this, then we are going to collapse this total incident time, right? So the idea is when to create the scenarios. Now every incident, like you every system that you are using, you can create a sub boundaries that this is a boundary of, for example, election night result system, we have a system to upload the election results to a website, right? And then the website publishes the result. So that's a subsystem, there is a boundary there, right? So that particular boundary, how many systems we have, what kind of attack vector we are going to face, right? What are the vulnerabilities? Well, so different aspect about the system, the systems profile itself, what we have to defend it from? What do we have in our hand? What is what is the mechanism that we have in place for detection? What is the defense mechanism that we can avoid the issue itself, right? And then how are we going to recover and restore? Right? So all of these factors, once you consider, you might be able to come up with a single page plan. And this is a scenario for only one kind of incident, not for system for only one kind of incident for that specific boundary, right? And everything that you have at your hand is in that one document, right? One page item. What we have in the defense, how critical this issue is, who do we contact in case of the incident? What do we talk to the two other teams? How do we communicate to the public? How do we communicate internally? Right? What are the symptoms of the issues? Right? Everything is documented in this one page document per incident type, right? And I'm going to go later into how many incident scenarios that we are going to make. But for one particular incident, every information that you need to handle that incident is in one page. Now, that's a lot of work. When you start developing this incident scenario template, you might run into the issues like, we don't have an answer. If you have an answer for a particular item, that's not the answer that you like, right? But this is this is the idea that when you are doing this in off election cycle, you're going to find your own gaps that what gaps we have in our protection mechanism to avoid the issue itself. What are the gaps that we have in our detection system? That's not efficient. And then that necessary waste, reducing the necessary waste. How can we do something better to detect the issue? Right? What is the response mechanism that we have in place? Can you automate it? Right? Do we need a human intervention? So all of those questions are going to come up and going through this one scenario might take days, right? You are going to involve your system owner, your security staff, IT staff, everyone, right? But once you get rolling, then you are going to get an idea, and you're going to get to the new next scenario, next scenario, and so forth, right? But once we have this template, then now you're ready to roll, right? You are avoiding much of that necessary waste time while incident is in progress, right? That's the idea. So there's a simple example, election night reporting system. We have one system that publishes the result to the general public and then there is a system that we are using to upload, for example, right? There is an internal network from where we are uploading the result and then there is the internet where everyone else is getting that results, right? So we have two lines, two communication lines, and two points, right? There might be more than one server, there might be more than one system, but the type of machine is only one and I mean two here, right? So two lines, two points, there are four different places where that we have to protect, right? Seven different kind of vulnerabilities that we are going to protect it from, right? And what are we, what is our end goal? You know, maintaining the confidentiality, integrity and availability, three different outcomes, right? You have 84 different scenarios for this one subsystem, right? And for every scenario, we are going to make a plan like that, right? In a searchable format, in a filterable format, so when you need it, as soon as you have some indication, symptoms, some searchable phrase in that system, it is going to bring up exact scenario that how we are going to handle that. One another thing I forgot to mention here is the options, right? So based option, next based option and the worst case scenario. So the idea is when you mature these scenarios, we have only one day for the election, right? And in election night result, it's mostly like after 6pm till 10pm, everybody is going to watch it. So you have very small window where the system is going to be useful, right? So your best option, you should be able to do within few minutes, less than 10 minutes first, for example, right? Something that you could do right away within 10 minutes that you can get the system back up and normal, right? If that doesn't work, there's the next based option, maybe an hour, we don't have much time, right? And the worst case scenario is we are going to declare a major incident and we are going to work on for a long time, right? But you are going to try to figure out like what is my best case, what I can do very quickly, right? So back here. So we have 84 different scenarios in this case, right? Now if you consider all the different kind of sub boundaries, right? There will be a lot of hundreds and hundreds of scenarios. Now there is a mechanism of collapsing the scenario because our idea is to develop a response plan. So many of those attacks, you might have an exact same response, right? And if in that case, you can collapse that scenarios, right? But we still have developed about more than 200 scenarios like this in our runbook. Now, once you have this scenario, now we need an overarching process of when the incident happens. What do we do step by step? What technical steps? What communication step or management steps we are going to take and when we are going to declare incident, how we are going to prioritize and so forth. So Tanya is going to cover the communication and overall incident management process aspect. And there's a template for that too. We like templates. So there's a template for that too. So she will explain more about the overarching process template. Thanks Rahul. So here we provided a template for incident response processes, which details the flow of information and communications and elections office. On the top level, you'll see we've outlined sample systems and the contact information for each system owner. For example, we have physical security, our tally system or election management system, our ePoll book, our voter registration system, our mail voting system, election results, voting systems, etc. Other systems that any election office can fill in. On the next level, we have a decision step. Is this a security incident? Or is it operational or some other type of incident? If yes, it is a security incident, then we move to the next level where we activate our analysis and prepare for activating our teams. Rahul went over our sample scenario templates, we would review those and any others that are in our incident management handbook. We've identified low priority incidents where internal members of our team would review the analysis and prepare for a resolution. Moderate incidents are ones where we would engage our vendors or other state or federal officials such as DHS and highly incidents are those where we would engage our communications team for external messaging. On the next level, we've outlined the relevant work groups. So for Cook County in Chicago, we have elections IT, we have security, elections management and communications. But in smaller jurisdictions where election officials wear several hats and there are very cross functional teams, their staff could easily modify the template and make it useful for their offices. On the last step, we have post incident review where we look at what went well, what can be approved and what changes or process are needed in the steps. So to quickly summarize, the Cook County Clerk's Office and Chicago Board of Elections Commissioners internally developed incident response and management tools based on recommendations from this EISAC and Hartford Belfort Center. It's truly a multifaceted approach for consistent and systematic processes. Our offices are working year round on continuous improvements and we hope that the public will gain a greater level of confidence knowing that local election officials are using well utilized and improved incident response plans. So here we've listed some references which are included in the white paper. The white paper will be tweeted out by the voting village and will also be posted on the Cook County Clerk's website. If there are any local election officials present today, we're happy to meet with you after the session and talk about the template in a little more detail. And if we have time, we can answer a few questions now as well. Okay, thanks. Yeah, yeah. Each election cycle, we review the plans. We have a weekly cybersecurity meeting where we go into detail about new developments and that includes not only our IT team, but as well as the elections management and security. Yeah, that's that's a very good point. I mean, this is not a one time job, right? I mean, we have to review it. And in all off election cycle, typically we have a election in either March or April and then November. So off election cycle, this should be reviewed with all the system owners, right? And whenever you have a technical change, like your detection mechanism changes, your protection mechanisms changes, then it has to be updated, right? We have an experience standing not to that. You know, I mean, not to the medium or high level. So nothing that that's, you know, affected us from the recovery point of view. Yes. So, um, yeah, I mean, that that's very important because we rely on our partners a lot. We are lucky. We are in Chicago. I mean, Cook County and city of Chicago and they have a DHS, um, region five head office. I want to say yes, uh, is is in Chicago. So every off election cycle, we do, uh, they have a whole publication of services that they provide for all the critical infrastructure. We leverage each and everyone of them right on in off election cycle, either it's a cyber hygiene, um, a red team, um, the remote penetration testing, so many things that they offer, uh, even physical security, and we leverage them on election day. We invite all of our partners, uh, even the Verizon or any other, you know, I mean, the, the, your, uh, communication partners, uh, DHS is on site. Um, uh, and they are there on the election day. Uh, we, we start at like three or four a.m. around and then stay till one o'clock at midnight, but they are, they are there, uh, most of the time. Um, yeah, I mean, IT partners, security partners there, and then we have a, um, I'm not sure if, uh, if, uh, if it is available to all the jurisdiction, but there is a situation room, so we are on the situation room on the election day all day. Uh, yeah, so it's very important that, that communication line is open in your, uh, election cycle and all the planning activity you can always schedule in a off-election cycle. Last question. Sorry. Yes. Yes. So like Tanya mentioned earlier, if you are election officials and if you need, uh, I mean, need to discuss this further, we can definitely share the approach. Um, we can help you develop your own template. Um, and, uh, this PowerPoint and, and the paper will be tweeted out by the DEF CON and it will be available on our websites as well. Sorry. Sorry. We can meet you after the, okay. Thank you.